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PREFACE 


An  Air  Traffic  Control  (ATC)  system  can  be  developed  to  provide  fuel- 
efficient  routings  routinely,  to  increase  controller  productivity  and  to  reduce 
system  errors.  This  system,  called  AERA,  is  described  in  this  document.  The 
concept  document  describes  a  system  that  is  an  evolutionary  extrapolation  of  the 
many  techniques  that  FAA  has  pioneered  during  the  past  decade,  such  as  conflict 
alert,  en  route  metering,  Automatic  Traffic  Advisory  and  Resolution  Service 
(ATARS),  Discrete  Address  Beacon  System  (DABS),  trajectory  modeling  and 
planning  algorithms,  and  electronic  tabular  displays  (ETABS). 

This  concept  document  was  prepared  by  a  team  of  ATC  experts  to  review 
prior  work,  the  on-going  AERA  program  and  to  define  a  total,  AERA  concept.  The 
review  team  has  concluded  that  the  concept  is  feasible,  the  degree  of  automation 
implied  can  be  achieved  with  state  of  the  art  equipment,  that  the  system  can  be 
designed  so  that  no  aircraft  would  be  placed  in  hazard  by  system  failures,  and 
finally,  that  AERA  has  benefits  that  are  substantially  larger  than  its  costs. 

The  team  of  experts  that  authored  this  document  have  been  reassembled  to 
assist  in  developing  a  plan  and  associated  evolution  strategy  for  the  AERA  program. 


AERA  CONCEPT  DESCRIPTION 


1.0  Introduction 


This  document  is  a  concept  description  of  AERA,*  an  advanced  air  traffic 
control  system,  currently  under  development,  that  reduces  controller  workload  by 
automatically  performing  routine  aircraft  separation,  traffic  flow,  and  clearance 
generation,  delivery  and  acknowledgment  functions.  Reductions  in  controller 
workload  and  the  capability  of  a  computer  to  detect  and  resolve  multi-dimensional 
potential  conflicts  permit  a  substantial  relaxation  in  procedural  limitations  to  the 
use  of  airspace.  This,  in  turn,  permits  the  widespread  use  of  fuel  efficient  profiles 
and  direct  routings  while  substantially  decreasing  controller  workload.  System 
errors  will  probably  be  reduced  when  controllers  are  relieved  of  routine  functions. 
Thus,  AERA  should  improve  productivity  and  safety  for  both  the  users  and 
operators  of  the  system. 

AERA  should  limit  procedural  restraints  on  the  use  of  airspace  to  isolated 
traffic  "hot  spots"  incapable  of  reliable  algorithmic  conflict  resolution.  The  freer 
movement  of  traffic  should  not  burden  the  controller,  because  AERA  plans  and 
monitors  the  three  dimensional  flow  of  traffic  automatically  over  a  planning  region 
that  incorporates  a  number  of  sectors,  and  in  a  conflict-free  and  metered  manner. 
It  is,  therefore,  not  necessary  for  the  controller  to  visualize  an  entire  complex 
traffic  flow,  and  then  plan,  implement  and  monitor  efficient  conflict  resolutions. 
The  controller's  productivity  is  increased  because  routine  functions,  such  as  the 
transmission  and  acknowledgement  of  clearances,  are  mechanized.  Furthermore, 
AERA  reduces  the  number  of  sectors  required  so  that  the  number  of  transfers  of 
control  responsibility  will  decrease. 

*AER/ .  -  *  hi  ,rically  an  acronym  for  Automated  En  Route  Air  Traffic  Control, 

but  its  p.v/ouctivity  and  safety  advantages  are  more  important  attributes  than  its 
degree  of  automation;  and  furthermore,  AERA  is  applicable  to  some  portions  of 
terminal  airspace.  Therefore,  AERA  is  used  as  a  noun  rather  than  an  acronym  in 
this  concept  description. 
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However,  the  controller  can  intervene  and  evaluate  the  quality  of  service  at 
any  point  in  the  ATC  process,  reviewing  planned  traffic  flows,  metering,  conflict 
resolution,  clearance  generation  or  individual  aircraft  performance.  The  controller 
is  the  manager  of  AERA,  evaluating  situations  best  resolved  by  human  judgment 
and  utilizing  AERA's  algorithms  to  accomplish  routine  tasks.  Despite  the  use  of 
DABS  data  link  and  Voice  Response  Systems  (VRS)  to  transmit  and  acknowledge 
clearances  whenever  possible,  controllers  will  be  available  at  all  times  to  negotiate 
clearances  with  aircrews  needing  or  desiring  service. 

FAA  has  developed  a  great  variety  of  computer-driven  aids  for  the  controller 
over  the  past  two  decades.  Some  significant  examples  are  flight  plan  processing, 
automatic  altitude  reporting  and  display,  minimum  safe  altitude  warning  and 
conflict  alert.  Algorithms  are  now  being  developed  for  DABS/ATARS,  as  well  as 
for  NAS  Stage  A  and  ARTS,  to  provide  controllers  and  aircrews  with  conflict 
resolution  advisories.  AERA  accomplishes  its  goals  by  applying  and  extending 
these  currently  available  computer  aids. 

AERA  will  accept,  in  most  instances,  an  aircrew's  requested  flight  profile, 
the  altitude/speed  trajectory  that  is  usually  selected  to  minimize  fuel  burn. 
Alternatively,  AERA's  algorithms  have  been  developed  to  accept  user-filed  "hori¬ 
zontal"  flight  plans,  and  to  associate  a  trajectory  with  that  flight  plan,  taking  into 
account  aircraft  type,  gross  weight  and  winds  aloft.  Computer  projections  of  flight 
plans  over  10  to  30  minutes,  can  reveal  potential  separation  violations.  Conflict 
resolution  algorithms  are  being  developed  to  resolve  potential  separation 
violations.  These  conflict  resolutions  are  generated  in  such  a  way  as  to  minimize 
deviation  from  the  desired  flight  plan.  Flow  control  limitations  on  delivery  rates 
to  adjoining  regions  or  airports  can  be  provided  by  apportioning  delays  to  aircraft 
in  the  AERA  planning  region  and,  when  necessary,  by  limiting  incoming  flow  to  the 
planning  region.  Algorithms  can  be  developed  to  translate  the  flow  control 
limitations  into  flight  plan  revisions  and  instructions  to  neighboring  regions  in  order 
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to  limit  flows  as  required.  The  conflict  resolution  algorithms  and  delay  apportion¬ 
ment  algorithms  can  be  developed  in  such  a  way  as  to  mutually  satisfy  each 
requirement.  The  simultaneous  and  interactive  solution  of  the  conflict  resolution 
and  delay  apportionment  algorithms  can  be  accomplished  using  available  computer 
technology  and  in  a  time  much  less  than  aircraft  transit  time  through  the  planning 
region.  An  AERA  functional  block  diagram  is  shown  in  Figure  1-1. 

A  single  aircraft's  deviation  from  expected  performance,  may  require 
changes  to  the  flight  clearances  of  other  aircraft  in  the  planning  region.  These  can 
be  calculated  and  transmitted,  if  necessary.  Gross  perturbations  to  the  planned 
flow,  due  to  changes  in  airport  capacity,  severe  weather  or  navigation  equipment 
outage  will  be  processed  to  modify  the  flight  plans  of  all  affected  aircraft  in  such  a 
way  as  to  cause  minimum  deviation  and  fuel  consumption  and  so  that  all  potential 
conflicts  remain  resolved  and  all  needed  delays  are  incorporated  in  the  modified 
flight  plans. 

AERA  relieves  the  controller  and  air  crew  from  routine  tasks  that  lead, 
however  infrequently,  to  system  errors.  But  the  mechanization  of  these  tasks 
cannot  extend  to  complex  situations  that  are  difficult  to  handle  algorithmically  and 
are  best  left  to  man's  judgment.  Furthermore,  neither  the  aircrew  nor  controller 
can  be  put  into  a  situation  beyond  their  capability,  even  in  the  case  of  massive 
system  failures.  In  case  of  a  partial  or  total  center  failure,  traffic  flow  will  be 
caused  to  diminish  automatically  to  rates  and  densities  such  that  separation  can  be 
assured  by  controllers  aided  by  whatever  resources  remain.  This  could  be 
accomplished  by  continuously  generating  and  then  transmitting  and  storing  backup 
clearances  in  neighboring  centers,  DABS  sites,  RCAGs  and  TRACONs  as  appro¬ 
priate,  for  transmission  to  aircraft  should  a  center  fail.  Traffic  in  this  reduced 
mode  could  be  handled  from  adjoining  centers,  or  TRACONs  and  towers,  if  this 
should  be  necessary.  In  fact,  there  will  probably  be  better  protection  against 
system  failure  in  AERA  than  at  present,  because  it  is  dealt  with  as  an  integral  part 
of  the  system  design. 
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Both  the  users  and  operators  of  the  air  traffic  control  system  would  benefit 
from  these  improvements.  The  users  would  obtain  fuel  conservative  direct  routings 
and  profiles.  The  operators  would  be  able  to  provide  improved  services  and  accom¬ 
modate  additional  traffic  without  any  increase  in  manpower.  These  improvements 
in  productivity  and  service  level  should  be  attainable  with  an  improvement  in 
safety. 

The  AERA  control  process  should  be  applicable  to  en  route  and  portions  of 
terminal  airspace.  It  requires  no  special  avionics  equipment,  although  AERA 
productivity  and  the  quality  of  service  it  can  provide,  would  be  dramatically 
improved  as  aircraft  become  equipped  with  the  Discrete  Address  Beacon  System 
(DABS),  Area  Navigation  (RNAV)  capability,  and  a  Flight  Management  System. 

The  development  of  AERA  requires  major  efforts  in  system  design  and 
software  and  man-machine  interface  development.  The  testing  of  AERA  in  a 
simulator  and  in  a  real  traffic  environment  are  also  considerable  efforts.  The 
needed  hardware  is  within  the  state  of  the  art.  Special  configurations  of  current 
production  hardware  are  needed  to  meet  reliability  and  failure  mode  requirements. 
The  9020R  program,  to  replace  current  en  route  computers,  should  be  designed  to 
accept  the  AERA  system,  with  only  minor  augmentations.  AERA  imposes  no 
special  requirements  on  the  nature  of  ATC  communication,  surveillance  and 
navigation  systems  and  can  be  designed  to  interface  with  those  systems  currently 
implemented  or  which  are  now  being  procured. 

Full  AERA  involves  flight  plan  optimization  over  a  number  of  sectors  using 
wind,  weather  and  aircraft  data  with  little  need  for  procedural  restrictions;  it  can 
accept  flow  control  directives  to  meter  traffic  in  a  fuel-conservative  way;  it  can 
generate  and  transmit  flow  control  requirements  to  contiguous  control  facilities  or 
the  national  flow  control  system;  it  can  detect  potential  conflicts  and  resolve  them 
without  major  disturbance  of  desirable  flight  plans;  it  can  automatically  generate, 
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transmit  and  accept  acknowledgement  of  conflict-free  clearances;  it  can  auto¬ 
matically  monitor  flight  performance  to  assess  the  need  for  revised  clearances;  it 
can  provide  interfaces  for  controllers  at  the  planning,  clearance  generation  or 
individual  aircraft  monitoring  levels  of  ATC;  it  can  be  so  designed  that,  in  case  of 
failure,  it  can  be  recovered  by  controllers,  even  under  substantial  traffic  flows. 
The  implementation  of  full  AERA  is  predicated  on  the  replacement  of  current  en 
route  computers  since  they  do  not  have  the  capacity  to  handle  all  these  functions. 
But  significant  elements  of  AERA  would  be  useful  in  the  current  NAS  system  and 
could  be  mechanized  in  augmentation  processors  attached  to  the  current  NAS 
system. 

For  example,  in  today's  ATC  system,  there  are  procedural  restrictions  that 
keep  aircraft  at  inefficient  low  altitudes  or  on  circuitous  routings.  These 
procedures  are  prearranged  among  ATC  facilities  to  ensure  that  potentially 
conflicting  traffic  flows  will  always  be  separated,  either  laterally  or  vertically, 
after  allowing  for  a  range  of  individual  deviations.  Since  the  flows  are  separated, 
limited  deviations  need  not  be  dealt  with  and  individual  clearances  need  not  be 
coordinated  with  other  ATC  sectors  or  facilities.  Since  the  limiting  factor  which 
leads  to  the  imposition  of  procedural  restrictions  is  the  controller's  capacity  to 
coordinate  clearances  —  and  not  airspace  saturation  with  aircraft  —  a  more 
automated  process  for  coordinating  individual  flight  clearances  should  greatly 
reduce  the  need  for  rigid  flow  restrictions. 

For  example,  in  the  case  of  a  specific  procedurally  restricted  altitude  on  an 
airway  in  the  Northeast,  a  potential  conflict  with  higher  altitude  overflights,  if 
there  were  unrestricted  flows  between  the  two  streams  of  traffic,  would  occur  only 
one  percent  of  the  time  (see  Chapter  5  for  details).  The  conflict  detection  and 
resolution  algorithms  of  AERA  might  well  provide  useful  coordination  information 
to  the  controllers  in  these  sectors  to  enable  them  to  safely  handle  the  interact  .ons 
between  these  two  streams  of  traffic.  Many  features  of  AERA  are  not  needed  for 
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this  limited  capability,  features  such  as  metering,  automatic  generation  and 
transmission  of  clearances  and  full  failure  mode  attributes.  The  few  needed 
features  of  full  AERA  might  be  incorporated  in  am  augmentation  processor  to 
NAS  Stage  A. 

Another  early  application  of  AERA  attributes  might  be  to  provide  some  NAS 
Stage  A  sector  controllers  with  a  partial  AERA  system  that  would  incorporate 
optimum  flight  profile  generation,  conflict  prediction  and  resolution,  delay 
absorption  and  clearance  generation,  but  that  would  not  include  automatic 
clearance  transmission  aind  acknowledgement  nor  the  failure  modes  required  in  the 
full  AERA.  The  controller  would  still  have  final  authority  to  issue  clearances,  but 
he  would  have  a  substantial  planning  and  control  aid  provided  by  AERA.  The 
purpose  of  such  an  application  would  be  to  provide  certain  incremental  controller 
productivity  improvements  and  fuel  efficiency  for  users. 

There  are  other  possibilities  for  interim  "products"  to  spin-off  from  the  full 
AERA  program.  The  development  of  AERA  interim  " products "  is  appropriate,  not 
only  because  of  the  useful  service  they  can  provide  before  the  en  route  computers 
can  be  replaced,  but  also  because  they  provide  feedback  to  the  design  of  the  full 
AERA,  and  they  provide  for  the  evolutionary  incorporation  of  AERA  features  into 
the  ATC  system.  The  development  and  implementation  of  AERA  interim 
"products"  should  not  compromise  the  development  of  full  AERA.  An  expanded 
discussion  of  interim  AERA  products  is  contained  in  Appendix  1,  "An  Incremental 
Approach  to  AERA  Implementation." 

This  concept  document  describes  the  need  for  AERA,  the  AERA  features  that 
satisfy  these  needs,  AERA's  impact  on  the  utilization  of  airspace  and  its  organi¬ 
zation,  the  interaction  between  AERA  and  the  controller  and  the  air  crew,  the 
impact  of  AERA  on  communications,  the  failure  mode  requirements  on  AERA  and 
the  techniques  for  meeting  these  requirements. 
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2.0  The  Need  for  AERA 


The  requirement  for  AERA  flows  from  the  following  needs: 

•  To  reduce  operating  costs  to  airspace  users  by  permitting  direct,  fuel- 
efficient  profiles. 

•  To  reduce  operating  costs  to  the  U.S.  government  by  increasing  ATC 
specialist  productivity. 

•  To  accommodate  the  growing  number  of  IFR  flights  with  minimum 
additional  cost. 

•  To  increase  flight  safety  by  reducing  system  errors  through  an  improved 
ATC  system. 

Even  seemingly  minor  reductions  in  fuel  consumption  due  to  direct  fuel- 
efficient  profiles  have  major  impacts  on  airline  profitability  as  can  be  seen  from 
Figure  2-1,  where  it  is  shown  that  a  3  percent  saving  in  fuel  consumption  is 
reflected  into  a  potential  30  percent  improvement  in  airline  profitability. 

It  is  shown  in  Section  5  of  this  document,  that  AERA  techniques  can  be  used 
to  aid  in  removing  a  procedural  limitation  to  the  use  of  fuel  conservative  altitudes 
in  a  portion  of  the  New  York  ARTCC.  Aircraft,  until  recently,  were  limited  to 
16,000-17,000  feet  on  the  New  York  to  Washington  route,  as  compared  to  the 
desired  altitudes  of  24,000-26,000  feet.  This  caused  a  fuel  penalty  of  7  to  8 
percent.  A  recent  procedural  change,  permitting  these  aircraft  to  attain  20,000- 
21,000  feet,  reduces  the  penalty  to  approximately  3  percent.  But  procedural 
separation  still  requires  La  Guardia  to  Washington  traffic  to  be  delivered  to  the 
Ensue  fix  north  of  National  and  requires  Kennedy  to  Washington  traffic  to  be 
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delivered  to  Nottingham  south  of  National,  whether  the  airport  is  operating  to  the 
north  or  south.  Due  to  this,  and  other  factors,  during  off-peak  hours  on  weekends 
the  New  York  to  Washington  flight  takes  approximately  45  minutes  due  to  fairly 
direct  routing,  while  normally  it  takes  60  minutes  in  the  absence  of  runway 
queuing. 

Thus,  altitude  and  route  procedural  limitations  can  cause  substantial  fuel 
penalties  compared  to  optimum  routings  particularly  on  short  stage  lengths.  Using 
optimum  routings  during  periods  of  light  traffic,  flight  times  that  are  achieved  are 
frequently  significantly  better  than  the  published  schedules.  Of  course,  schedules 
are  based  on  procedurally  restricted  routings  that  are  used  during  periods  of 
"normal"  traffic  and  adverse  wind  conditions. 

This  phenomena  occurs  in  many  hub  areas.  Based  on  an  understanding  of  the 
amount  of  traffic  serving  major  hubs,  on  the  specific  procedural  factors  identified 
above,  3  percent  seems  a  reasonable  estimate  of  the  national  fuel  savings  that 
might  be  achieved  using  AERA  techniques.  This  is  obviously  an  estimate  that 
needs  refining. 

The  domestic  airline  fuel  bill  was  approximately  $6  billion  in  1979.  It  is 
expected  to  be  35  percent  greater  in  1980.  Assuming  a  3  percent  saving  in  fuel  due 
to  AERA,  there  would  be  a  $250  million  saving  in  1980.  The  present  value  of  such 
a  saving  is  approximately  $2.75  billion  at  a  10  percent  discount  rate.* 

IFR  traffic  is  expected  to  grow  over  the  next  decade  by  62  percent,  with  the 
greatest  growth  concentrated  in  general  aviation  and  air  taxis  as  shown  in 
Figure  2-2.  Without  any  changes  in  the  way  traffic  is  handled,  this  would  imply 
about  a  60  percent  increase  in  work  force,  since  it  does  not  seem  that. additional 
NAS  Stage  A  productivity  improvements  are  available. 

*In  this  concept  paper,  present  values  are  determined  on  the  assumption  that  there 
is  an  instantaneous  step  function  implementation  and  that  the  discounted  stream  of 
benefits  persists  into  the  future.  Thus, 'the  present  value  is  the  annual  benefit 
times  the  factor  (1  +  i)/i  where  Ms  the  discount  rate.  Obviously  implementation 
rates  extend  over  a  period  of  time  and  the  resulting  benefits  build  up  gradually.  It 
would  be  highly  conjectural  to  predict  an  implementation  schedule  and  the  schedule 
of  resulting  benefits  at  this  time.  Reasonable  assumptions  on  implementation 
schedules  do  not  change  significantly  the  present  value  benefit/cost  ratios  resulting 
from  a  step  function  implementation  and  benefit  schedule. 
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IFR  Aircraft  Handled  by 
FAA  Air  Route  Traffic  Control  Centers, 
Fiscal  Years  1873  -  1990 


45.6 


FY  1978  Status  FY  1978  —  90  Forecast 
(Growth)  (Total  Growth) 


General  Aviation 

19% 

120% 

Air  Taxi 

19% 

205% 

Air  Carrier 

5% 

28% 

Military 

0% 

0% 

Total 

8% 

62% 

Sources  Detailed  forecast  of  "IFR  Aircraft  Handled" 
(Report  Not  FAA-AVP  79-1) 

Figure  2r2 


During  the  last  decade,  controller  productivity  improved  by  approximately  30 
percent,  according  to  Figure  2-3,  due  presumably  to  the  relatively  minor  computer 
aids  provided  by  NAS  Stage  A.  Based  on  various  analyses!*  V  one  would  expect  at 
least  a  100  percent  improvement  in  controller  productivity  from  full  AERA,  beyond 
the  improvements  provided  by  NAS  Stage  A.  Thus  the  productivity  improvement  of 
AERA  should  more  than  offset  the  additional  workload  due  to  forecasted  traffic 
growth.  The  annual  value  of  the  AERA  productivity  improvement,  including 
handling  the  forecasted  traffic  growth,  is  approximately  $300  million  at  1979  costs. 
This  benefit  is  derived  by  increasing  the  $375  million  annual  expense  (1979)  to 
operate  25  ARTCCS  (See  Figure  2-3)  by  1.6,  to  account  for  the  increase  in  traffic, 
and  taking  50  percent  of  this  as  the  benefit  due  to  AERA  productivity.  The  present 
value  of  such  a  saving  is  approximately  $3.3  billion  at  a  10  percent  discount  rate. 
Therefore,  the  present  value  of  the  fuel  saving  and  control  productivity  improve¬ 
ment  due  to  AERA  is  estimated  to  be  $6  billion. 

Verified  Air  Traffic  Control  System  errors  have  been  occurring  at  an  average 
rate  of  1.5  per  day.  A  system  error  is  a  violation  of  separation  standards  caused  by 
an  ATC  mistake.  Over  50  percent  of  these  errors  fall  into  four  categories: 
coordination,  inattention,  communication  and  poor  judgment,  as  can  be  seen  from 
Table  2-1.  Coordination  includes  the  failure  to  coordinate  an  action  with  the  next 
controller  before  handoff  or  use  of  another  controller's  airspace.  Poor  judgment 
includes  the  inability  to  predict  conflicts  between  converging  aircraft  of  different 
speeds,  under  or  over  estimating  climb  performance,  inability  to  predict  high  speed 
military  aircraft  turn  performance.  Approximately  one-half  of  these  system  errors 
occur  in  en  route  airspace  and  two-thirds  in  en  route  and  TRACON  airspace.  These 
system  errors  are  precisely  the  kind  of  mistake  that  AERA  is  designed  to  overcome 
and  they  are  occurring  in  the  airspace  AERA  is  designed  to  serve.  There  is  no 
reliable  way  to  estimate  the  monetary  value  of  the  improved  safety  that  AERA 
should  provide. 

Thus,  AERA  should  help  improve  safety  and  save  substantial  costs  to  the 
operators  and  users  of  the  ATC  system. 
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Table  2-1 

Frequencies  of  Probable  Causes 
Number  of  SE's  with  Causes  Given  297 


Percent  of 

Category  Frequency  Causes 


1 

55 

18.52% 

2 

30 

10.10% 

3 

39 

13.13% 

4 

15 

5.05% 

5 

16 

5.39% 

6 

14 

4.71% 

7 

39 

13.13% 

8 

17 

5.72% 

9 

7 

2.36% 

10 

7 

2.36% 

11 

8 

2.69% 

12 

4 

1.35% 

13 

1 

0.34% 

14 

12 

4.04% 

15 

8 

2.69% 

16 

4 

1.35% 

17 

1 

0.34% 

18 

5 

1.68% 

19 

9 

3.03% 

20 

1 

0.34% 

21 

3 

1.01% 

22 

1 

0.34% 

23 

1 

0.34% 

24 

0 

0.00% 

25 

0 

0.00% 

Category  Name 

Coordination 

Inattention 

Communication 

Lack  of  ATC  instructions 

Delayed  ATC  instructions 

Insufficient  ATC  instructions 

Judgment 

Forgetting 

Flight  strip  data 

Handoff 

Workload 

Transponder 

Speed  restriction 

System  hardware 

Pilot  deviation 

Relief  briefing 

Clearance  to  wrong  aircraft 

Bad  entry  to  computer 

Aircraft  identification  confused 

Controller  didn't  recognize  emergency 

Inadvertant  data  information  given 

Oceanic  miscalculation 

Training 

Track  coasting 

Military  facility  deviation 


Sources  FAA  Aircraft  Separation  Assurance  Studies  and  Briefings,  1978. 


3.0  AERA  System  Description 
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The  purpose  of  this  section  is  to  describe  the  concepts  and  overall  functional 
design  of  the  AERA  system.  It  points  out  where  the  system  design  has  roots  in 
ideas  proven  by  current  ATC  system  design  and  procedures,  or  where  it  goes 
beyond  tested  and  proven  concepts. 

The  AERA  system  can  provide  most  of  the  ATC  services  of  an  Air  Route 
Traffic  Control  Center  (ARTCC)  in  a  safer  and  more  productive  manner  than  the 
current  system.  The  design  concepts  are  being  applied  initially  to  positively 
controlled  en  route  and  transition  airspace  environments.  Extensions  to  controlled 
aircraft  in  mixed  low  altitude  environments  and  to  portions  of  terminal  area 
airspace  are  possible. 

This  AERA  system  description  is  organized  as  follows: 

First,  the  processes  involved  in  the  handling  of  controlled  flights  by  the 
current  ATC  system  are  presented,  along  with  the  factors  that  are  influencing 
changes.  The  best  of  current  ATC  practices  and  the  needed  changes  are  integrated 
into  several  design  postulates  for  the  AERA  system. 

Second,  the  distributed  nature  of  the  planning  and  execution  of  air  traffic 
control  functions  is  described.  The  major  system  elements  and  their  communi¬ 
cation  and  coordination  needs  are  discussed.  Key  organizational  concepts  in  the 
AERA  design  are  defined. 

Third,  the  major  functions  to  be  performed  in  AERA  are  described  in  some 
detail,  along  with  their  input/output  relationships  with  each  other.  External  data 
inputs  and  outputs  are  described  for  both  man-machine  communications  and  for 
data  communications  with  remote  facilities. 
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The  description  presented  in  this  section  presumes: 

1.  A  filed  flight  plan  on  every  controlled  flight  against  which  ATC 
clearances  are  generated. 

2.  Tracked  surveillance  data  on  the  position  and  altitude  information  on 
every  controlled  flight. 

3.  Communications,  data  or  voice,  with  every  controlled  flight. 

Not  treated  in  this  section  are  such  subjects  as: 

1.  Failure  modes  and  perturbations,  both  internal  or  external,  and  backup 
provisions  for  the  AERA  system  (see  Section  4). 

2.  The  potentials  for  extending  AERA  to  other  airspaces  and  to  achieve 
greater  expedition  and  freedom  of  flight  (see  Section  5). 

3.  The  expected  roles  and  responsibilities  of  the  human  operators  of  the 
AERA  system  (see  Section  6). 

4.  The  levels  of  service  provided  to  the  various  users  of  the  AERA  system 
as  a  function  of  aircraft  equippage  and  other  factors  (see  Section  7). 
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3.1  The  Air  Traffic  Control  System,  Now  and  in  AERA 

The  ATC  system  in  the  United  States  is  charged  with  the  safe  and  expeditious 
movement  of  flight,  in  particular  controlled  flights.  In  this  sense,  a  controlled 
flight  is  one  whose  operator  has  requested  permission  to  proceed  according  to  a 
flight  plan  filed  with  the  system,  and  who  has  received  in  return  an  ATC  clearance 
to  proceed,  with  or  without  restrictions  relative  to  that  flight  plan.  Clearances  are 
formulated  and  issued  to  ensure  that  (1)  aggregate  traffic  demand  does  not  exceed 
known  airport  or  ATC  facility  capacity  limits,  and  (2)  individual  flight  movements 
do  not  conflict  with  each  other.  In  this  process,  three  distinct  functions  can  be 
identified:  Pre-flight  and  In-flight  Planning;  Traffic  Flow  Management  (part  of 
ATC);  and  Traffic  Separation  and  Advisory  Services  (part  of  ATC).  The  relation¬ 
ships  between  AERA  and  these  three  functions  are  described  in  the  subsections 
below. 

A  fourth  function,  a  separate  Collision  Avoidance  capability,  is  related  to  the 
Traffic  Separation  and  Advisory  Service  in  the  sense  that  it  is  also  dedicated  to 
preserving  air  safety,  but  it  stands  outside  the  ATC  system  in  that  it  operates 
independently  of  the  flight  planning,  clearance  planning,  and  traffic  control 
process.  Such  collision  avoidance  systems  as  the  Air  Traffic  Advisory  and 
Resolution  Service  (ATARS)  and  the  Beacon  Collision  Avoidance  System  (BCAS) 
will  back  up  the  ATC  system  whether  the  latter  is  equipped  with  AERA  or  not.  As 
in  the  current  system,  ATARS  and  BCAS  are  being  designed  as  additional  back-up 
safety  services  to  provide  last  minute  traffic  advisories  or  avoidance  maneuvers  in 
the  event  that  ATC  separation  methods  have  failed  (IFR-IFR  encounters)  or  do  not 
apply  (1FR-VFR  and  VFR-VFR  encounters). 
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3.1.1  Pre-flight  and  In-flight  Planning 

In  the  current  ATC  system,  each  operator  of  a  flight  decides  the  objective  of 
his  flight  and  the  means  to  meet  that  objective  most  efficiently.  The  flight  plan  as 
currently  filed  with  the  ATC  system  is  a  partial  statement  of  the  operator's  full 
intent.  It  is  basically  a  request  of  the  ATC  system  for  a  clearance  to  proceed 
along  the  user's  filed  route  and  at  an  altitude  requested  by  the  user.  However,  the 
preferred  climb  profile,  speed  schedule,  etc.,  are  not  filed  with  the  ATC  system 
and  are  left  to  the  pilot's  discretion,  except  when  restricted  by  ATC  for  traffic  or 
procedural  reasons.* 

A  change  to  an  existing  flight  plan  clearance  can  be  requested  at  any  time  by 
the  pilot.  Typical  reasons  include:  a  more  favorable  altitude,  a  more  direct  route, 
avoidance  of  severe  weather  or  turbulence,  etc.  ATC  will  grant  such  requests 
whenever  feasible. 

It  is  now  possible  to  refine  flight  plans  prior  to  departure  or  to  revise  plans  in 
flight  so  as  to  minimize  fuel  consumption  or  flight  time.  Accurate  knowledge  of 
aircraft  performance  characteristics,  the  flight's  operating  environment,  winds 
aloft,  and  significant  weather  is  made  possible  through  modern  sensor,  computer 
and  communications  technologies  so  that  flight  plans  can  be  optimized.  For  those 
users  who  do  not  have  access  to  their  own  preflight  planning  systems,  commercial 
services  are  available.  The  FAA's  Flight  Service  Station  Automation  program  is 
directed  towards  providing  users  with  improved  terminal  and  en  route  forecasts, 
winds  aloft  data,  and  other  flight  planning  aids. 

For  in-flight  planning,  performance  advisory  computers  are  available  which 
advise  the  pilot  as  to  the  thrust  and  pitch  settings  needed  to  achieve  the  altitude 
profile  and  speeds  which  best  minimize  user  costs,  fuel  consumption,  or  flight  time. 
Flight  management  computers  are  available  which  can  be  coupled  to  flight  control 

•The  flight  plan  form  does  ask  that  the  pilot  make  an  estimate  of  the  flight's  true 
airspeed  (TAS)  for  the  purpose  of  estimating  fix  arrival  times.  But  the  data  in  the 
TAS  field  is  not  interpreted  as  a  request  for  an  ATC  assignment  as  are  the  data  in 
the  requested  route  and  altitude  fields. 
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systems  via  auto-pilots  and  auto-throttles.  Such  systems  ensure  that  the  computed 
best  pitch  and  thrust  settings  are  translated  into  the  proper  flight  control 
instructions.  A  flight  management  computer  integrated  with  an  area  navigation 
system  automatically  provides  optimum  speed  and  altitude  profiles  over  any 
desired  route. 

While  the  current  ATC  system  tries  to  satisfy  each  user's  request  for  a 
particular  route  or  altitude,  restrictions  are  imposed  as  needed  to  ensure 
separation  and  expeditious  traffic  flow.  As  the  controller's  workload  increases, 
procedural  route  and  altitude  restrictions  are  often  imposed  between  potentially 
conflicting  traffic  flows  so  as  to  limit  this  workload.  Since  routine  imposition  of 
altitude  or  routing  restrictions  segregate  potential,  but  not  necessarily  actual 
traffic,  the  result  is  that  aircraft  are  frequently  denied  the  use  of  empty  airspace. 
This  is  commonly  referred  to  as  "separating  aircraft  from  airspace,"  rather  than 
separating  aircraft  from  other  aircraft.  The  consequences  are  circuitous  routing 
and  undesirable  altitudes  leading  to  higher  operating  costs,  fuel  burns,  or  flight 
times  than  would  have  otherwise  been  necessary. 

Rising  fuel  costs  and  improved  avionics  lead  the  users  to  need  and  request 
optimum  direct  routes,  and  unrestricted  altitude  profiles  and  speed  schedules.  It  is 
becoming  increasingly  important  that  the  ATC  system  accommodate  these  user 
requests. 

In  the  AERA  system  concept,  flight  planning  is  accomplished  as  follows: 

1.  The  airspace  users  will  continue  to  be  responsible  for  establishing  their 
own  mission  objectives  and  whatever  flight  plans  are  needed  for 
achieving  them  most  efficiently.  However,  with  the  introduction  of 
airborne  computers  to  make  such  flight  planning  optimal  and  data  links, 
it  now  becomes  possible  to  transmit  this  more  detailed  knowledge  of 
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flight  intent  to  the  ATC  system  for  use  in  planning  conflict-free  and 
metered  clearances.  While  the  traditional  flight  plan  format  may  be 
adequate  for  making  initial  flight  clearance  requests,  it  is  inadequate 
for  communicating  desired  climb  and  descent  profiles,  speed  schedules 
and  other  supplemental  data  to  the  ATC  system.  Regardless  of  aircraft 
equippage,  ACRA,  as  explained  in  Section  3.3.2,  will  monitor  aircraft 
performance,  interject  control  as  required  to  ensure  conflict-free 
metered  flow,  establish  flow  patterns  to  avoid  saturation,  and  reroute 
aircraft  around  severe  weather. 

2.  The  ATC  system  will  continue  to  be  responsible  for  clearing  all  flight 
movements,  subject  to  aircraft  separation  and  flow  constraints.  How¬ 
ever,  to  the  extent  that  the  users  are  willing  and  able  to  keep  the  ATC 
system  informed  of  their  current  intents  (planned  altitude  profiles, 
speed  schedules,  and  the  degree  of  conformance  to  be  expected),  the 
system  should  be  able  to  apply  this  knowledge  in  a  manner  which 
reduces  the  need  for  many  routinely-applied  procedural  restrictions. 

3.  To  the  extent  that  users  are  unwilling  or  unequipped  to  provide  more 
detailed  flight  plan  data,  the  AERA  system  will  be  designed  to  estimate 
an  aircraft's  flight  profile,  based  on  pre-stored  data  of  aircraft  type, 
winds  aloft  and  other  factors.  Since  it  is  only  a  guess,  the  residual 
uncertainty  as  to  what  will  actually  occur  must  be  compensated  for  by 
increasing  the  size  the  airspace  protected  for  that  aircraft.  Increasing 
the  volume  of  protected  airspace  increases  the  likelihood  that  an 
aircraft's  clearance  will  conflict  with  another's  clearance,  resulting  in  a 
less  desirable  clearance  for  at  least  one  of  the  aircraft  involved.  Thus, 
the  opportunities  for  less  restricted  clearances  increase  as  users  equip 
themselves  with  flight  management  computers  and  DABS  data  link 
which  can  communicate  the  planned  aircraft  trajectories  to  the  AERA 
system. 
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However,  AERA  could  operate  satisfactorily  in  the  absence  of  such 
aircraft  equippage.  While  the  initial  probability  of  control  actions 
increases  for  substantial  look  ahead  times,  greater  than  20  to  30 
minutes,  because  of  uncertainties  with  respect  to  flight  profile  and 
calculated  times  of  arrival,  the  AERA  planner  makes  dynamic  adjust¬ 
ments  when  needed  to  avoid  conflicts  as  flights  progress.  It  is  only 
necessary  to  ensure  —  as  explained  in  Section  3.3.2  —  that  the  density 
of  aircraft  projected  at  a  given  point  in  time  and  space  does  not  burden 
AERA  and  aircraft  with  overly  complex  future  clearances. 

3.1.2  Traffic  Flow  Management 

Airports  have  capacity  limits  on  aircraft  operations  which  vary  as  a  function 
of  weather,  runway  configuration,  traffic  mix,  and  other  factors.  ATC  facilities 
have  flight  handling  capacities  which  vary  as  a  function  of  current  staffing,  on-line 
computer  resources  and  air-ground  communication  channels.  To  provide 
expeditious  and  fuel-efficient  flight  movements,  the  ATC  system  is  becoming 
increasingly  organized  and  automated  to  improve  its  ability  to  (I)  match  variable 
ATC  resources  to  anticipated  traffic  demands;  and  to  (2)  regulate  actual  demands 
to  match  limited  ATC  and  airport  capacities.  This  process  conceptually  extends 
from  the  arrival  airport  to  its  TRACONs  and  through  ARTCCs  back  towards  the 
departure  airports.  The  process  is  physically  implemented  within  a  distributed 
nationwide  network  of  ATC  facilities. 

In  the  current  system,  the  distributed  network  consists  of  three  types  of  ATC 
facilities: 


1  Central  Flow  Control  Facility  (CFCF) 

23  Domestic  Air  Route  Traffic  Control  Centers  (ARTCCs) 
150  Terminal  Radar  Approach  Controls  (TRACONs) 
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plus  non-radar  approach  control  facilities  and  traffic  control  towers  at  controlled 
airports.  For  additional  background  on  ARTCC/TRACON  interactions  see 
Appendix  2. 

The  operation  of  the  current  ATC  system  is  depicted  in  Figure  3-1.  A  major 
airport  is  shown  to  be  feeding  traffic  operating  under  instrument  flight  rules  (IFR) 
to  a  distant  major  airport.  This  traffic  merges  with  other  traffic,  both  IFR  and 
VFR  (visual  flight  rules).  As  long  as  demand  remains  within  the  capacity  of  the 
airport  and  is  within  the  capacity  of  the  arrival  TRACON  to  form  the  arrival 
sequence  with  little  or  no  delay,  the  arrival  ARTCC  feeds  aircraft  to  the  arrival 
TRACON  without  delay.*  When  landing  delays  are  anticipated  which  are  beyond 
the  capability  of  the  TRACON  to  absorb  efficiently,  the  TRACON  imposes  flow 
restrictions  on  arrivals.  Such  restrictions  maintain  those  aircraft  that  are  certain 
to  be  delayed,  at  higher  altitudes,  thereby  conserving  fuel.  See  Appendix  3  for  a 
description  of  landing  delay  absorption  in  a  fuel  efficient  manner. 

The  role  of  each  facility,  shown  in  Figure  3-1,  in  the  management  of  traffic 
flow  is  discussed  now. 

The  arrival  ARTCC  merges  arrivals  en  route  to  feeder  fixes  for  the  terminal 
area.  The  in-trail  spacing  is  chosen  to  ensure  safety  and  to  meet  any  flow  rate 
restrictions  that  may  be  required  at  the  feeder  fixes  by  the  TRACON.  Speed 
reductions  or  path-stretching  vectors  are  typically  employed  to  insert  any  needed 
modest  delays.  To  absorb  larger  delays  holding  patterns  may  be  required.  When 
sudden  losses  in  runway  capacity  are  experienced,  impromptu  holding  procedures 
may  be  employed,  such  as  present  position  holds  and  off-course  circular  vectoring 
patterns. 

Tier  ARTCCs  and  intermediate  ARTCCs  may  be  employed  to  absorb  some  of 
the  delay  when  the  arrival  ARTCC's  capacity  for  absorbing  landing  delays  is 

*VFR  arrivals  check  in  locally  with  the  TRACON  for  sequencing  and  spacing 
to  the  proper  runway. 
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expected  to  be  taxed  for  a  substantial  time  period.  A  tier  center  is  one  adjacent  to 
the  arrival  center  that  feeds  the  latter  a  significant  number  of  arrivals.  An 
intermediate  center  is  any  center  which  lies  between  the  departure  center  and  the 
tier  center  on  any  major  route  for  arrival  traffic.  For  example,  for  traffic  moving 
from  Los  Angeles  to  the  New  York  metropolitan  area,  Los  Angeles  is  the  departure 
center,  New  York  is  the  arrival  center,  and  either  the  Cleveland  or  the  Washington 
Center  is  the  tier  center,  depending  upon  whether  a  northern  or  southern  route  to 
New  York  is  chosen.  If  a  northern  route  to  New  York  is  chosen,  the  intermediate 
centers  are  Denver  and  Chicago. 

When  large  and  persistent  delays  can  be  forecasted  well  in  advance,  or  are 
detected  to  be  trending  so  as  to  severly  impact  operations,  the  Central  Flow 
Control  Facility  (CFCF)  will  intervene  to  effect  timely  and  efficient  coordination 
of  any  needed  flow  restrictions  which  transcend  center  boundaries.  These  may 
include  changes  to  bypass  constricted  routes. 

The  CFCF  is  the  focal  point  and  communications  center  for  implementing  the 
traffic  flow  management  function  at  the  national  level.  All  major  airports,  users, 
and  ATC  facilities  maintain  direct  voice  or  data  communications  with  the  CFCF. 
TRACONs  and  ARTCCs  keep  the  CFCF  informed  of  local  conditions  and 
capacities,  both  current  and  expected.  Data  on  planned  flights  to  saturable 
airports  or  via  saturable  routes  are  forwarded  from  all  over  the  nation  to  the 
CFCF.  There  the  aggregarate  demand  for  these  saturable  airports  and  routes  is 
forecasted.  The  forecasted  demand  on  these  facilities  is  compared  with  the 
acceptance  rates  estimated  to  be  available  when  that  demand  materializes.  When 
overloads  are  judged  to  be  likely,  contingency  plans  can  be  put  into  effect.  These 
bypass  en  route  constrictions  or  diminish  traffic  flow.  The  CFCF  also  is  a  clearing 
house  for  flow  constraints  that  other  ATC  facilities  initiate  on  inbounds  to  their 
airspaces.  The  CFCF  either  approves  the  contraint  and  helps  coordinate  its 
implementation,  or  it  may  suggest  alternatives  which  would  accomplish  the 
facility's  objective  with  less  impact  on  overall  system  performance. 
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The  departure  Tower/TRACON  obtains  clearance  planning  data  on  proposed 
IFR  departures  from  the  departure  ARTCC.  It  later  forwards  actual  departure 
times  and  other  flight-specific  data  to  the  departure  ARTCC  when  these  flights 
depart.  If  a  flight  is  destined  for  an  airport  with  Fuel- Advisory  Departure  (FAD) 
procedures  in  effect,  its  departure  may  be  postponed  so  as  to  take  its  assigned 
delay  on  the  ground,  rather  than  in  the  air.  To  the  extent  practical,  the  decision  as 
to  where  to  take  the  assigned  delay  is  left  to  the  individual  operator,  with  the 
understanding  that  all  of  the  assigned  delay  must  be  taken  before  his  flight  enters 
the  arrival  ARTCC's  airspace.  A  record  is  maintained  of  the  amount  of  delay 
assigned  and  the  amount  absorbed.  This  record  is  forwarded  with  the  other 
clearance  planning  data  for  the  flight  as  the  aircraft  moves  towards  its  destination. 

Traffic  Flow  Management  is  accomplished  by  this  distributed  system  of 
facilities  and  the  information  paths  needed  for  coordinating  the  plans  of  the 
various  facilities.  This  system  is  illustrated  in  Figure  3-2. 

In  the  current  system,  these  functions  are  performed  by  a  mix  of  automated 
and  manual  procedures,  and  data  exchanges  are  made  using  a  mix  of  voice  and 
digital  communications.  In  the  future,  the  topology  shown  in  Figure  5-2  is  not 
expected  to  change,  but  it  is  expected  that  the  functions  will  become  more  fully 
automated  (performed  by  computers  managed  by  facility  personnel)  and  that 
communication  facilities  will  become  more  reliant  on  digital  data  messages 
exchanged  between  computers. 

The  three  major  planning  and  control  functions  (Central,  En  Route,  and 
Terminal)  are  discrete  but  cooperating  entities  in  a  nationwide  network  of 
distributed  and  increasingly  automated  ATC  facilities.  A  fourth  functional  level  of 
ATC  planning  and  control,  Terminal  Configuration  Planning  and  Selection,  shown  in 
Figure  3-2,  involves  the  management  of  runways  at  a  given  airport.  This  function 
determines  the  appropriate  runway  configuration  for  various  wind,  weather,  noise 
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and  flow  considerations.  It  determines  the  runway  capacity  that  is,  or  will  be, 
available  for  a  given  airport  and  the  appropriate  arrival  and  departure  fixes. 

The  AERA  system  concept  manages  traffic  flow  as  follows: 

1.  The  four  functional  components  of  traffic  flow  management  are  main¬ 
tained:  Central  Flow  Control;  En  Route  Flow  Control;  TRACON/Tower 
Flow  Control;  and  Terminal  Configuration  Planning  and  Selection. 
AERA  will  accommodate  to  their  outputs. 

2.  Flight  clearance  planning  and  traffic  control  will  continue  to  be 
distributed  across  ARTCCs  and  TRACON/Towers.  Any  flow  constraints 
or  delay  maneuvers  are  planned  and  imposed  independent  of  juris¬ 
dictional  boundaries  so  as  to  minimize  delays  and  fuel  consumption. 

3.  The  CFCF  will  continue  to  be  the  focal  point  for  predicting  gross  delays 
and  for  coordinating  flow  constraints  which  cannot  be  predicted  or 
coordinated  as  efficiently  by  the  affected  ARTCCs  or  TRACON/Towers 
themselves. 

4.  Each  ARTCC  or  TRACON  has  to  know  only  that  portion  of  the  overall 
delay  which  is  to  be  absorbed  within  its  jurisdiction.  The  needed  delay 
is  made  known  to  a  facility  by  downstream  ATC  facilities  or  the  CFCF. 
The  plan  needed  to  absorb  delay  within  a  facility's  jurisdiction  is 
generated  by  the  facility  itself. 

5.  The  location  of  arrival  feeder  fixes  can  be  defined,  assigned,  or  changed 
depending  upon  which  runways  are  active,  the  direction  of  arrival,  and 
the  TRACON's  ability  to  handle  traffic  flow  merges  with  the  terminal 
area.  Even  if  arrival  feeder  fixes  do  remain  as  static  locations  (for 
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reasons  external  to  the  design  of  AERA),  the  crossing  altitudes  can  still 
be  allowed  to  float  as  a  function  of  the  best  altitude  profiles  for  the 
descending  aircraft. 

The  remainder  of  the  AERA  flow  management  description  concentrates  on 
the  traffic  flow  management  functions  housed  within  the  ARTCCs.  Any  functions 
unique  to  the  CFCF  or  to  TRACON/Tower  system,  such  as  terminal  area  flow 
management  and  airport  configuration  optimization  will  not  be  developed  further 
in  this  document.  However,  the  interaction  of  the  ARTCC  flow  management  with 
that  of  the  CFCF  or  TRACON/Tower  is  described. 

3.1.3  Traffic  Separation  and  Advisory  Services 

The  current  ATC  system  gives  first  priority  to  the  separation  of  controlled 
flights  and  to  the  issuance  of  safety  advisories.*  Second  priority  goes  to  other 
services  that  are  required  but  do  not  involve  the  separation  of  aircraft  (e.g., 
altime  _*r  settings).  Third  priority  is  given  to  additional  services  to  the  extent  that 
workload  and  other  factors  permit  (e.g.,  distributing  pilot  reports  of  weather). 

The  current  ATC  system  provides  separation  between  controlled  flights. 
Separation  in  either  the  horizontal  or  the  vertical  dimension  is  sufficient  to  assure 
safety.  In  the  horizontal  plane,  clearances  to  flights  along  routes  which  are 
laterally  separated  are  sufficient.  Where  lateral  separation  falls  below  some 
acceptable  minimum  (near  route  intersections  or  for  closely  spaced  routes),  and  the 
flights  involved  are  seen  and  identified  using  tracked  surveillance  data,  a  minimum 
range  standard  is  used.  Where  surveillance  coverage  is  insufficient,  pilot  reports  of 
position  are  used  and  a  minimum  time  or  DME  distance  separation  standard  is  used. 

Alternatively  in  the  current  ATC  system,  flights  can  be  separated  vertically 
from  each  other,  thus  eliminating  any  concern  about  the  possible  loss  of  horizontal 


•Safety  advisories  are  to  be  issued  whenever  any  air  traffic  controller  becomes 
aware  that  a  flight  (identified  and  in  contact  with  ATC)  is  in  an  unsafe  proximity 
to  terrain,  an  obstruction,  or  another  aircraft.  These  control  priorities  are  defined 
in  ATC  Handbook  7110.63. 
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separation.  When  applying  the  vertical  separation  standard  to  flights  that  are 
undergoing  a  transition  from  one  assigned  altitude  to  another,  all  altitudes  not  yet 
reported  as  vacated  must  be  protected  up  to,  and  including,  the  new  assigned 
altitude. 

Controllers  plan  and  execute  control  instructions  to  ensure  that  at  least  one 
of  the  established  separation  standards  will  always  be  satisfied  for  every  flight 
under  his  active  control. 

With  regard  to  traffic  separation  and  advisory  services,  the  AERA  design 
concept  is  as  follows: 

1.  The  ATC  system  will  continue  to  give  first  priority  to  the  separation  of 
controlled  flights  and  any  other  flights  that  are  granted  separation  or 
safety  advisory  services.  Should  a  conflict  arise  between  these  services 
and  satisfying  a  traffic  flow  management  constraint,  safety  has 
priority. 

2.  The  AERA  system's  ability  to  plan  conflict-free  clearances  should  be 
greatly  enhanced  over  that  of  the  current  ATC  system,  given  better 
data  on  the  actual  winds  aloft,  expected  aircraft  performance,  the 
planned  altitude  profiles  and  speed  schedules,  and  the  ability  to 
compute  the  projected  missed  distance  of  flight  trajectories  in  the 
horizontal  and  vertical  dimensions,  whether  or  not  these  trajectories 
are  on  airways.  Therefore,  it  should  be  possible  to  relax  many  of  the 
procedurally  imposed  ATC  restrictions  on  routes,  altitude  profiles,  and 
speeds  without  any  loss  of  safety. 

3.  Given  the  capability  to  automatically  monitor  the  progress  of  every 
controlled  flight  (a)  relative  to  its  own  current  clearance;  and  (b) 
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relative  to  the  progress  of  other  flights,  in  both  the  horizontal  and 
vertical  dimensions,  the  AERA  system  does  not  need  to  be  overly 
conservative  in  providing  separation  between  converging  flights.  This 
should  lead  to  greater  expedition  of  flight  than  is  permissible  in  the 
current  system.  Coupled  with  the  capability  to  automatically  compute 
clearances  on  a  tactical  basis  to  ensure  that  separation  standards  are 
satisfied,  the  amount  of  conservatism  practiced  in  clearing  flights 
today,  even  in  the  absence  of  procedurally  imposed  restrictions,  should 
be  reducible  without  any  loss  in  safety. 

A  goal  of  the  AERA  concept  is  to  relieve  the  human  controllers  from 
all  routine  monitoring  of  aircraft  tracks.  Controllers  now  routinely 
monitor  tracks  in  order  to  assure  that  at  least  one  of  the  minimum 
separation  standards  will  be  met.  This  function  can  be  performed  more 
consistently  and  accurately  using  computers,  given  reliable  surveillance 
data  provided  by  ATCRBS  or  DABS. 

5.  Given  that  the  tactical  resolution  of  any  residual  conflicts  can  also  be 
automated,  human  controllers  can  eventually  be  relieved  of  the  duty  of 
making  any  time-critical  decisions  regarding  flight  safety. 

6.  Controllers  are  required  to  be  on  duty  to  respond  to  any  special 
requests  or  situations  brought  to  their  attention  for  non-time-critical 
resolution.  There  must  always  be  enough  controllers  on  duty  to  handle 
the  voice  communication  peak  load,  which  is  likely  to  occur  during 
episodes  of  severe  weather  or  when  airports  are  changing  runway 
directions  or  have  curtailed  acceptance  rates.  Controllers  are  required 
to  assess  the  capacity  of  the  portion  of  the  system,  under  their 
responsibility,  the  status  of  alternative  routes  and  backup  capabilities, 
and  the  present  and  predicted  demand  as  provided  by  CFCF  and 
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adjoining  facilities.  Controllers  are  to  be  provided  with  special  AERA 
tools  to  make  these  assessments  and  thus  utilize  ATC's  resources  in  a 
manner  which  continuously  maintains  the  most  expeditious  traffic  flow 
without  compromising  safety.  For  further  discussion  of  the  role  of  the 
controller  in  AERA,  see  Section  6  entitled  "AERA  and  the  Controller". 

3.2  AERA  System  Elements,  Boundaries  and  Data  Exchanges 

The  following  paragraphs  define  the  network  of  ATC  facilities  within  which 
the  AERA  system  is  physically  housed.  The  airspace  boundaries  important  to  the 
AERA  concept  are  defined.  Finally  the  data  exchanges  needed  in  advance  of  flight 
movements  across  these  boundaries  are  defined. 

3.2.1  Air  Traffic  Control  Centers,  AERA  Systems  and  Inter-Facility  Interfaces 

As  shown  in  Figure  3-3,  there  are  currently  twenty  Air  Route  Traffic  Control 
Centers  (ARTCCs)  which  service  1FR  traffic  over  the  continental  United  States. 
Each  ARTCC  accepts  flight  plans  on  proposed  departures  from  airports  within  its 
boundary  and  on  active  inbounds  planning  either  to  overfly  its  interior  or  to  land  at 
airports  within  its  boundary.  It  uses  these  flight  plans  and  surveillance  data  to 
plan,  coordinate  and  control  these  flight  movements  so  that  they  remain  conflict- 
free  and  metered  relative  to  any  flow  rate  constraints. 

For  the  purpose  of  clarity,  this  system  description  starts  with  a  few  basic 
assumptions.  Some  of  these  assumptions  can  later  be  relaxed  as  various  options  are 
discussed,  such  as  center-center  consolidation,  center-terminal  consolidation, 
boundary  realignments,  and  subdividing  a  center  so  that  different  areas  of 
specialization  are  served  by  separate  computer  systems. 
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En  Route  Low  Altitude  ARTCC  Boundaries 
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It  is  assumed  that  there  is  one  AERA  system  per  ARTCC  facility.  Each 
AERA  system  has  data  communication  interfaces  with  its  neighbor  AERA  systems, 
as  well  as  with  the  computer  systems  in  the  TRACONs  and  Towers  it  serves, 
CFCF,  and  the  Flight  Service  Stations  (FSS)  and  other  on-line  sources  of  proposed 
flight  plans  within  its  service  area.  Voice  communication  links  between  operating 
personnel  in  ARTCCs,  TRACON/Towers,  CFCF,  and  FSS  facilities  are  also 
assumed  to  exist.  In  addition,  the  remote  voice  communications,  air-ground 
(RCAG)  sites  and  surveillance  and  data  link  communication  sites  (DABS)  which 
provide  coverage  of  each  center's  primary  airspace  service  volume,  plus  any 
secondary  backup  service  volumes,  are  assumed  netted  to  the  ARTCC  voice  or 
AERA  systems  (see  Figure  3-4). 

It  is  also  assumed  that  the  nationwide  network  of  ARTCC  computers  will 
continue  to  provide  the  backbone  for  storing  and  forwarding  flight  plan  data  to  all 
ATC  facilities.  Each  proposed  flight  plan  is  filed  with  the  ARTCC  which  serves 
the  departure  airport.  The  departure  ARTCC  performs  acceptance  checking  on  the 
flight  plan  and  handles  the  editing  of  any  errors  or  necessary  revisions.  If  the 
flight  plan  is  for  a  destination  of  interest  to  the  CFCF*,  then  the  ARTCC 
computer  forwards  the  necessary  data  to  the  CFCF  at  the  proper  time.  Sometime 
prior  to  the  proposed  departure  time,  the  proposed  flight  plan  is  processed  to 
permit  the  departure  clearance  to  be  formulated.  If  the  departure  is  from  an 
airport  served  by  a  TRACON**  or  Tower,  the  ARTCC  computer  forwards  the 
necessary  flight  data  to  the  TRACON/Tower  at  the  proper  time. 

When  the  flight  actually  departs,  the  departure  time  is  forwarded  by  the 
Tower  or  TRACON  to  the  ARTCC  computer.  Consequently,  its  flight  plan  is 
activated  and  flight  progress  monitoring  for  store  and  forwarding  purposes  begins. 
Sometime  prior  to  exiting  the  departure  ARTCC,  the  active  flight  plan  data  are 
forwarded  to  the  next  ARTCC  or  TRACON  down  the  route  of  flight. 

*CFCF  only  concerns  itself  with  saturable  major  airports  and  other  possible 
bottlenecks  to  major  traffic  flows  (e.g.,  routes  affected  by  severe  weather  or  ATC 
facility  outages). 

**TRACON-served  towers  are  assumed  to  receive  the  necessary  departure  data  via 
the  TRACON. 
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If  the  flight  does  not  enter  ARTCC  airspace  but  continues  under  "tower  en 
route"  procedures  through  adjacent  TRACON  or  tower  airspaces*  flight  plan 
forwarding  may  be  handled  either  by  the  ARTCC  or  the  TRACON  or  Tower 
computers*  depending  upon  the  capabilities  of  the  latter. 

In  the  current  NAS  Stage  A  and  Automated  Radar  Terminal  System  (ARTS) 
systems,  all  flight  plan  forwarding  is  handled  by  the  ARTCC  computers.  If  the 
ARTCC- to- ART CC  link  is  maintained  as  the  path  for  forwarding  all  flight  plans, 
then  the  arrival  ARTCC  has  all  the  data  necessary  to  perform  tentative  scheduling 
for  the  en  route  metering  function.  If  some  flight  plan  data  are  forwarded  by  a 
new  TRACON-to-TRACON  link,  then  the  arrival  ARTCC  and  arrival  TRACON  will 
both  have  flight  data  required  by  the  tentative  scheduling  function.  (See  Section 
3. 3. 2.5,  "Delays  Prediction".) 

3.2.2  IFR  Clearances 


The  concept  of  planned  "IFR  clearances"  is  essential  to  the  planning  function 
of  air  traffic  control.  In  its  simplest  form,  the  clearance  provides  the  pilot  with  an 
authorization  to  proceed  along  his  filed  route  at  an  ATC-assigned  altitude. 
Whenever  possible,  the  ATC-assigned  altitude  is  equal  to  the  pilot's  requested 
altitude.  The  clearance  may  be  revised  whenever  requested  by  the  pilot  or 
whenever  required  by  the  contingencies  of  air  traffic  control  (e.g.,  competing 
aircraft  movements,  hazardous  weather,  airport  closures,  etc.).  Revisions  may 
include  pilot-requested  or  controller-negotiated  re-routes,  new  altitude  assign¬ 
ments  or  altitude  crossing  restrictions,  speed  restrictions,  tactical  heading  or 
course  assignments,  clearance  limits  and  holding  instructions,  or  any  other 
instruction  authorized  by  ATC  procedures.  If  for  any  clearance  "at  pilot 
discretion"  is  stated  or  is  procedurally  implicit,  the  pilot  has  the  option  to  initiate 
the  terms  of  the  clearance  whenever,  and  however,  he  wishes.  Otherwise,  the  pilot 
is  expected  to  execute  its  provisions  without  delay  after  acceptance.  It  should  be 
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remembered  that  a  clearance  transmitted  to  a  flight  cannot  be  considered 
operative  until  pilot  acceptance  has  been  received  by  the  issuing  ATC  facility. 

3.2.3  Pilots,  Controllers  and  Man-Machine  Interfaces 

Even  though  flight  planning,  navigation  and  flight  control  have  become  highly 
automated  functions  in  many  aircraft,  the  pilot-in-command  has  final  responsibility 
for  the  safe  conduct  of  his  flight.  However  automated  ATC  flight  clearance 
planning,  execution  and  tactical  control  eventually  become,  the  controller-in- 
charge  will  have  final  responsibility  for  safe  and  expeditious  operations  in  his 
sector,  within  the  bounds  of  his  assigned  role  (see  Section  6,  "AF.RA  and  the 
Controller").  In  order  to  meet  these  responsibilities,  the  pilot  and  controller  must 
have  the  ability  to  communicate  with  each  other,  as  well  as  with  the  computer 
systems  which  serve  them.  In  turn,  the  computer  systems  which  serve  them  should 
also  have  the  ability  to  exchange  specific  types  of  data.  Figure  3-5  illustrates  this 
communication  requirement.  Table  3-1  summarizes  the  possible  sources  for 
messages  delivered  by  the  air-ground  data  link. 


HAN-MACHINE  AND  AIR-GROUND  COMMUNICATIONS  ASSUMED  IN  AERA 
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Table  3-1 

Possible  ATC  Data  Message  Generation  and  Delivery  Techniques 

Down-Link  Messages 

On-Board  Computer-to-Down-Link: 

Direct  with  pilot  review/approval 
Via  pilot  for  review/approval  or  revision 
On-Board  Computer-to-Pilot  for: 

Pilot-to-controller  negotiated  decision  or  data 
Pilot  relay  via  voice  radio  (backup) 

Pilot-to-on-Board  Computer  for: 

Relay  via  down-link  (primary  or  voice  backup) 

Processing  run/stops  which  may  generate  additional  down-link  messages 
Up-Link  Messages 

Ground-based  Computer-to-Up-Link: 

Direct  without  controller  review/approval  (or  revision) 

Via  controller  for  review/approval  (or  revision) 

Ground-based  Com  put  er-to-Contr  oiler  for: 

Controller-to-pilot  negotiated  decision  or  data 
Controller  relay  via  voice  radio  (backup) 

Con  troll  er-to-Ground-based  Computer  for: 

Relay  via  up-link  (primary  or  voice  backup) 

Processing  run/stops  which  may  generate  additional  up-link  messages 
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The  airborne  computer(s)  of  interest  here  include  those  used  for  planning  the 
best  speed  and  altitude  profiles  from  the  aircraft's  present  position  to  a  specified 
destination  (flight  management  or  performance  advisory  computers),  for  navigating 
a  selected  route  (area  navigation  computers  with  or  without  autopilot  coupling), 
and  for  conforming  to  a  selected  altitude  profile  and  speed  schedule  (a  flight 
management  computer  with  auto-pilot  and  auto-throttle  coupling).  While  such 
computers  are  not  necessary  for  the  implementation  of  AERA,  the  service  provided 
would  be  improved  for  aircraft  carrying  this  equipment. 

The  down-link  is  expected  to  become  the  primary  channel  for  pilot  acknowl¬ 
edgement  of  up-link  delivered  messages,  for  making  pilot  requests  using  flight 
planning  data  stored  in  his  own  computer  and  for  reporting  winds  aloft  and  other 
air  mass  data  (see  Table  3-2). 


Table  3-2 


Possible  ATC  Data  Message  Class/Type 


Down-Link  Messages 

1.  Flight  Plans  (proposed,  active  inbounds,  airfiles,...) 

2.  Flight  Profile  Data  (gradients,  speed  schedules,  Estimated  Time  of 
Arrival  (ETA)...) 

3.  Air  Mass  Data  (winds  aloft,  Clear  Air  Turbulence  (CAT),  cloud  tops...) 

4.  Clearance  Requests  (present  position  directs,  route  amendments,  Pre¬ 
ferential  Departure  Route  (PDR)/Perferential  Arrival  Route  (PAR) 
assignments,  runway  assignments...) 

5.  Discretionary  Requests  (lateral  route  deviations,  vertical  profile 
deviations...) 

6.  Information  Requests  (down-route  winds  aloft,  significant  weather, 
Automatic  Terminal  Information  Service  (rvTlS),  Cockpit  Display  of 
Information  (CDTI),...) 

7.  Up-link  Messages  Replies  (WILCOs,  Unables,...) 

Up-Link  Messages 

1.  Clearances  (route,  heading,  speed,  altitude,  voice  frequency  changes,...) 

2.  Advisories  (traffic,  terrain,  Significant  Meterological  Data  (SIGMETS), 
Notice  to  Airmen  (NOT AMS),...) 

3.  Information  Replies  (down-route  winds  aloft,...,  CDTI  updates,...) 

4.  Other  Down-Link  Message  Replies  (accepts,  rejects,...) 


42 


The  up-link  is  expected  to  become  over  time  the  primary  channel  for  ail 
messages  generated  by  the  ground  system's  computers.  Voice  radio  must  be 
retained  to  transmit  messages  to  aircraft  not  equipped  with  data-link  and  to 
facilitate  communications  not  made  easier,  or  possible,  by  the  computer  and  as  a 
backup  to  data  link  failures.  For  those  aircraft  not  equipped  for  data  link 
communications,  computer-generated  up-link  messages  might  be  delivered  via  the 
controller's  voice  channel  using  computer  voice  generation.  Limited  down-link 
messages,  like  acknowledgements,  derived  from  pilot  keyboard  entry,  might  be 
relayed  as  audio  tones  on  the  voice  channel. 

i 

The  only  experience  that  civil  ATC  has  had  with  air-ground  data  communi¬ 
cations  is  in  the  automatic  reporting  of  altitudes  and  assigned  beacon  codes  via  the 
ATCRBS  system.  This  idea  has  proved  to  be  highly  successful,  and  it  is  now  being 
expanded  into  a  full-fledged  data  link  in  the  upgraded  Beacon  system  (DABS). 

3.2.4  AERA  Planning  Regions 

To  avoid  discontinuities  in  the  planning  and  control  process,  each  AERA 
system  begins  full  trajectory  modeling  and  tracking  of  an  inbound  aircraft's 
progress  before  it  enters  the  control  region.  Nominally,  the  full  planning  process 
for  each  aircraft  begins  thirty  minutes  prior  to  inbound  handoff.  Conceptually 
then,  the  planning  region  for  each  AERA  system  is  larger  than  the  control  region 
by  nominally  thirty  minutes  flying  time.  Thus,  AERA  techniques  extend  beyond  the 
AERA  control  regions  into  the  AERA  planning  region,  but  a  given  AERA  system 
has  responsibility  for  separation  assurance  and  metering  only  within  its  control 
region. 
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3.2.5  AERA  Control  Regions 

In  each  AERA  system,  the  volume  of  airspace  within  which  the  computer  will 
regulate  flight  movements  by  issuing  clearances  to  pilots  is  known  as  its  "control 
region".  The  lateral  boundary  of  such  a  region  will  in  most  cases  be  coincident 
with  the  ARTCC  boundary.  Vertical  boundaries  will,  at  least  initially,  exclude 
terminal  areas  and  some  low  altitude  airspace  areas.  Control  regions  can  be 
defined  in  other  ways,  so  long  as  they  are  mutually  exclusive  and  collectively 
exhaustive  of  the  airspace  to  be  covered. 

3.2.6  AERA  Control  Sectors 


Each  AERA  control  region  is  subdivided  into  "control  sectors"  for  the  purpose 
of  assigning  teams  of  human  controllers  to  manage  airspace  jurisdictions  which  are 
smaller  than  the  whole  AERA  control  region.  Sectot  ization  is  provided  as  one 
mechanism  to  distribute  anticipated  human  workloads  among  several  control 
teams.  Any  configuration  of  sectors  is  supportable  so  long  as  they  are  mutually 
exclusive  and  collectively  exhaustive  of  the  parent  AERA  control  region.  Sectors 
can  be  (1)  combined  as  workload  decreases,  releasing  personnel  from  sector 
management  and  control  responsibilities  when  they  are  no  longer  needed,  and  (2) 
decombined  as  workload  increases,  in  order  to  keep  active  team  personnel  within  a 
range  of  productive  but  nonsaturating  workload  levels. 

While  not  critical  to  the  concept,  it  is  generally  assumed  that  AERA  control 
sectors  will  likely  be  staffed  by  one  or  two  controllers  and  that  the  airspace 
subsumed  would  be  several  times  the  size  of  current  day  NAS  sectors. 

As  in  the  present  system,  each  AERa  sector  will  maintain  VHF/UHF  radio 
communications  with  each  flight  under  its  control.  Assuming  that  it  will  take 
several  RCAG  sites  to  provide  continuous  coverage  over  each  AERA  sector,  the 
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AERA  system  would  automatically  instruct  each  flight  to  contact  the  center  on  a 
new  voice  frequency  as  it  moves  from  the  coverage  volume  of  one  RCAG  to  the 
next  (assuming  that  non-interfering  frequencies  are  required  between  adjacent 
RCAGs).  Properly  equipped  aircraft  could  have  voice  frequencies  changed 
automatically  from  the  ground.  AERA  may  require  fewer  voice  frequency  changes 
because  of  increased  sector  sizing  and  lower  message  traffic. 

3.2.7  Flight  Data  and  Control  Coordination  Across  Boundaries 

Figure  3-6  illustrates  the  sequential  process  of  flight  data  acquisition  and 
initial  clearance  planning,  track  data  acquisition  and  full  clearance  planning,  and 
inbound  transfer-of-control,  all  of  which  must  be  successfully  completed  before  an 
inbound  may  enter  the  AERA  control  region.*  Within  the  control  region,  flight 
trajectory  planning  is  conducted  as  though  control  sector  boundaries  were  not 
there,  with  one  exception.  AERA  provides  the  option  to  adapt  sector  shelves  and 
to  dynamically  activate  them  during  periods  of  high  demand  to  segregate  traffic 
flows.  While  the  use  of  such  shelves  is  expected  to  decline  with  the  imple¬ 
mentation  of  AERA,  this  feature  does  provide  a  means  of  transition  from  the 
current  system  and  a  mechanism  to  protect  against  unusual  demand  overloads. 

3.3  ATC  Functions  That  Involve  AERA 


The  functions  that  provide  inputs  to  AERA  are  discussed  first.  Then  the 
functions  to  be  performed  within  the  AERA  system  are  defined.  Flight  trajectory 
modeling  and  association  checking  are  described  to  show  how  the  planning  of 
clearances  can  be  based  on  flight  trajectory  models  and  to  show  that  real-time 
surveillance  of  actual  aircraft  progress  is  used  to  update  flight  trajectory  models. 
The  prediction  of  potential  problems  between  competing  flight  trajectories  is 
discussed  next  in  terms  of  predicted  "conflicts"  and  "delays".  The  planning  of 
cross-teli  messages  to  the  next  ATC  facility  down  each  route  of  flight  is  also 


•All  of  these  ideas  are  derived  from  current  ATC  practices  and  computer  system 
operations. 


AERA  Planning  Region 


Flight  Data  and  Control  Coordination  Across  Boundaries 


46 


discussed.  Next,  the  use  of  predefined  strategies  for  solving  the  catalogue  of 
potential  problems  is  discussed.  This  generates  a  plan  of  subsequent  actions  to  be 
taken  by  AERA.  The  interpretation  and  execution  of  the  planned  actions  to  meet 
explicit  tactical  objectives  are  discussed  next.  At  this  point  specific  messages 
needed  to  convey  clearances  or  other  data  are  generated. 

AERA  outputs  to  either  the  uplink  or  cross-tell  links  are  then  discussed.  The 
system  supervisory  functions,  monitoring  capacity,  demand  and  performance  are 
discussed  last. 

The  ATC  functions  are  described  from  the  viewpoint  of  an  observer  watching 
the  inner  workings  of  AERA,  and  the  information  flows  to  and  from  the  man- 
machine  interface  are  identified,  but  any  details  of  display  and  data  entry  are 
beyond  the  scope  of  this  concept  description. 

3.3.1  Inputs  to  AERA 

The  inputs  required  for  AERA  consist  of  various  air-to-ground  communi¬ 
cations,  other  on-line  data  inputs  from  ATC  facilities  and  "Radar"  data  inputs. 

3.3.1. 1  Air-to-Ground  Communications 


Air-to-Ground  Commur  ications  will  be  used  to  the  extent  that  served  flights 
are  equipped  to  down-link  flight  plans  ("airfiies"),  other  ATC  service  requests, 
flight  planning  data  (crew-planned  altitude  profiles  and  speed  schedules),  and 
sensed  air  mass  data  (winds  aloft,  outside  air  temperature,  turbulence,  etc.) 
Acknowledgement  of  up-linked  clearances,  instructions  and  advisories  ("will  com¬ 
ply",  "unable",  "understood",  etc.)  will  also  be  down-linked. 


Down-link  messages  are  either  routed  to  the  AERA  system  ("on-line  data 
inputs")  or  to  the  cognizant  sector  controller  ("Man-Machine  Interface"),  as 
message  addressing  dictates. 

Down-link  messages  can  be  transmitted  via  the  DABS  data  link  or  via  tone- 
encoded  messages  derived  from  pilot  keyboard  entry,  and  transmitted  over  the 
sector  voice  frequency. 

To  the  extent  that  aircraft  are  not  equipped  to  down-link  such  data, 
VHF/UHF  voice  radio  communications  will  be  used  and  the  controller  must  enter 
the  appropriate  data  in  AERA. 

3.3.1.2  Other  On-Line  Data  Inputs 

Other  on-line  data  inputs  to  the  AERA  system  come  from  local  sources  (e.g., 
Man-Machine  Interfaces),  and  external  facilities  (e.g.,  neighboring  ARTCCs,  served 
TRACONs  and  Towers,  CFCF,  center  area  FSS,  ATCRBS  and  DABS  sites  providing 
ARTCC  coverage,  etc.)  Messages  from  adjacent  ATC  facilities  include  proposed 
and  active  flight  plans,  flow  restrictions,  handoff  offers  and  acceptances,  and  many 
others.  All  inputs  are  checked  for  source  acceptability  and  content  errors  before 
being  used  to  update  AERA  data  bases. 

In  particular,  the  Man-Machine  Interface  function  provides  the  input  tools 
necessary  for  facility  supervisors  and  air  traffic  controllers  to  make  on-line  inputs 
into  the  AERA  system.  Such  inputs  might  be  made  in  response  to  a  request 
received  by  the  controller  from  a  served  flight  or  from  some  other  ATC  position, 
or  in  response  to  a  prompt  or  a  query  generated  by  the  AERA  system  itself,  or  to 
obtain  a  computer  response  to  a  question  formulated  or  to  a  decision  made  by  the 
supervisor  or  controller.  These  inputs  —  which  could  be  made  using  some  mix  of 
tactile  devices,  touch  displays,  or  speech  recognition  systems  —  are  automatically 
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error-checked  and  transformed  for  AERA  consumption  by  the  Man-Machine  Inter¬ 
face  function.  The  results  can  be  thought  of  as  additions  or  changes  to  those 
AERA  data  structures  which  either  control  or  feed  AERA  functions. 

Weather  data  sources  are  needed  to  support  the  following  functions: 

Winds  Aloft  Modeling:  Ground  speed  estimates  for  each  flight  must  be 
derived  from  its  expected  airspeed  schedule  and  other  data.  To  obtain  along- 
course  wind  data,  a  model  of  the  winds  aloft  will  be  maintained  for  use  by  the 
Trajectory  Modeling  function.  The  source  data  for  initializing  and  updating 
the  model  could  range  from  currently  available  NOAA  winds  aloft  reports/ 
forecasts  to  real-time  winds  aloft  reports,  the  latter  downlinked  by  equipped 
aircraft.  Ground  derivation  of  winds  aloft  can  be  computed  using  selected 
aircraft  tracks. 

Severe  Weather  Avoidance:  Severe  weather  data  must  be  made  available  to 
support  the  planning  of  clearances  to  safely  avoid  it.  The  minimum 
requirement  is  to  define  and  display  the  airspace  volumes  which  are 
potentially  dangerous  or  which  are  to  be  avoided.  The  pilot  can  request  and 
the  controller  can  initiate  the  necessary  processing  to  obtain  a  clearance 
which  either  authorizes  the  pilot  greater  later ai/vertical  discretion  about  his 
cleared  route  centerline  or  which  provides  him  with  a  revised  route 
clearance. 

Other  ATC  Services  to  Pilots:  The  following  are  currently  provided  as  en 
route  ATC  services  to  pilots  or  are  used  in  ATC  clearance  planning: 

•  Altimeter  Setting 

•  Minimum  Assignable  Flight  Level  (MAFL) 

•  Airport  Ceiling,  Visibility,  Runways  In  Use 

•  En  Route  Weather  Reports/Forecasts 
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This  information  will  continue  to  be  made  available  to  controllers  and  pilots 
by  AERA  even  though  the  methods  of  delivery  and  display  may  become  more 
automated. 

For  a  discussion  of  the  output  side  of  the  Man-Machine  Interface  function, 
refer  to  Section  3.3.3.2  entitled  "Other  On-Line  Data  Outputs." 

3.3.2  AERA  Functions 


The  seven  major  functions  within  AERA  and  their  logical  interfaces  with  the 
outside  world  are  illustrated  in  Figure  3-7.  The  particular  function  of  Strategic 
Planning  is  later  sub-divided  into  its  problem  prediction  functions  (delays,  con¬ 
flicts)  and  its  solution  planning  functions  (absorption,  resolution  and  solution 
checking).  This  further  breakdown  is  illustrated  in  Figure  3-11. 

3.3.2. 1  Surveillance  Data  Inputs  Processing 

Surveillance  Data  Inputs  Processing  converts  the  incoming  stream  of  surveil¬ 
lance  data  and  other  current  event  reports  (e.g.,  inbound  handoff  offers)  into  forms 
suitable  for  subsequent  computation.  For  example,  surveillance  data  not  previously 
tracked  is  smoothed  into  current  estimates  of  aircraft  position  and  speed 
("tracks").  The  parameters  used  by  AERA  in  association  checking,  conflict 
prediction  and  resolution  will  reflect  the  quality  of  the  tracks.  Current  track  data 
and  track  control  status  (offered  or  accepted)  are  made  available  to  such  functions 
as  Association  Checking,  Tactical  Execution,  Separation  Assurance  Monitoring  and 
the  Man-Machine  Interface. 

This  function  is  essentially  the  Radar  Data  Processing  (RDP)  function  in  NAS 
Stage  A. 


MAJOR  AERA  FUNCTIONS  A  INTERFACES 


A  data  base  which  ia  built  froai  1.  Includes  Conflict  Prediction  A  2.  Used  in  the  generic  sense  to  include 

processed  real-tiae  inputs  (local  Resolutions  Planning,  plus  Delays  instructions  A  advisories, 

or  resnte)  or  pre-stored  values.  Prediction  A  Absorption  Planning. 

3.  The  Man-Nachioe  Interfaces  are 
not  explicitly  shown. 


m 
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3.3. 2.2  Flight  Data  Inputs  Processing 

Flight  Data  Inputs  Processing  converts  incoming  messages,  such  as  each  new 
flight  plan  or  subsequent  revision  which  is  received,  into  an  internal  form  suitable 
for  subsequent  computation.  For  example,  the  alpha-numeric  route  field  must  be 
converted  into  a  set  of  (x,  y)  points  referenced  to  the  ARTCC's  coordinate  system. 

Procedural  restrictions  may  be  locally  adapted  and  dynamically  activated  as 
the  need  exists.  Any  procedural  restrictions  appropriate  to  a  particular  flight  plan 
are  also  noted  relative  to  its  converted  route  for  subsequent  processing.  The  flight 
planning  data  base  is  made  available  to  the  Flight  Trajectories  Modeling  and  the 
Man-Machine  Interface  functions. 

This  function  is  essentially  the  front-end  of  the  current  Flight  Data 
Processing  (FDP)  function  in  NAS  Stage  A. 

3.3.2.3  Flight  Trajectories  Modeling 

Flight  Trajectories  Modeling  takes  each  converted  horizontal  route  from 
planning  inputs  processing  and,  using  the  best  available  data  on  expected  aircraft 
performance  (climb  and  descent  speed  schedules,  altitude  profile  gradients,  etc. 
transmitted  by  the  flight  or  obtained  from  prestored  tables)  and  on  expected  winds 
aloft  (along  course  winds  at  profile  altitudes),  computes  a  best  estimate  of  the 
flight's  expected  trajectory  through  the  AERA  planning  region.  That  trajectory  is 
constructed  to  satisfy  known  boundary  constraints  (i.e.,  where  and  when  the 
aircraft  is  expected  to  enter  and  leave  the  planning  region),  as  well  as  any  interior 
planning  region  constraints  (e.g.,  procedurally  imposed  crossing  altitude 
restrictions). 
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The  trajectory  can  be  thought  of  as  an  ordered  sequence  of  4-dimensional 
point  (x,  y,  z,  t),  where  each 

x,  y=  a  flight  plan  fix  or  a  fix  defining  one  end  of  a  flight  plan  airway 
segment,  or  a  point  where  the  flight  plan  route  crosses  an  internally 
stored  boundary  (e.g.,  sector,  restricted  area,  weather  cell,  metering), 

or  a  point  where  a  change  in  course,  altitude  gradient  or  speed  is  expected 
to  take  place. 

z  =  the  currently  expected  altitude  when  crossing  the  point  "x,  y". 

t  =  the  currently  expected  time  of  arrival  at  (or  departure  of)  the  point  "x, 

y". 

Stored  with  each  point  are  all  the  relevant  data  associated  with  the  flight  at  that 
point.  Pairs  of  such  points  define  "state  segments".  State  segments  are  connected 
end-to-end  to  make  a  trajectory  for  each  flight  which  traverses  the  planning 
region. 

Figure  3-8  illustrates  the  printout  of  the  horizontal  profile  of  such  a 
trajectory.  When  submitted  for  horizontal  route  conversion,  this  horizontal  path 
was  described  as  "CHS.J165.RIC..EPICS..DCA".  Figure  3-9  illustrates  the  printout 
of  the  corresponding  vertical  profile  for  that  trajectory. 

Associated  with  each  trajectory  is  a  list  of  Clearance  Directives  which 
represents  traffic  control  actions  planned  for  subsequent  execution  at  specific 
points  along  the  trajectory.  Each  Clearance  Directive  states  an  explicit  tactical 
objective  to  be  met  by  this  flight.  When  initially  created,  the  Clearance  Directive 
List  contains  only  an  outbound  handoff  Clearance  Directive  and  any  procedurally 
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adapted  Clearance  Directives  which  apply  (ideally  none  are  required).  Other 
Clearance  Directives  may  need  to  be  added  after  the  flight  trajectory  has  been 
processed  for  delays  prediction  and  absorption  planning,  as  well  as  conflicts 
prediction  and  resolution  planning,  in  the  Conflict,  Delays  Prediction  function 
shown  in  Figure  3-11. 

Each  Clearance  Directive  has  an  activation  point  marked  as  an  along-route 
distance  measured  from  the  local  trajectory  origin.  As  described  later  in  more 
detail,  a  clearance  prompt  is  generated  by  the  Association  Checking  function  when 
the  flight's  track  crosses  the  activation  point. 

In  NAS  Stage  A.  horizontal  profiles  are  built,  but  vertical  profiles  are  not. 
Crude  ground  speed  profiles  are  built  for  fix  times  calculation,  but  are  based  on 
very  limited  knowledge  of  what  the  pilot  is  actually  planning  to  do  and  current 
winds  aloft.  In  AERA,  a  significant  improvement  is  expected  in  the  ability  to 
predict  where  an  aircraft  will  be  in  space  and  time.  This  will  permit  significant 
reduction  in  the  size  of  the  prediction  and  protection  error  buffers  that  would 
otherwise  be  required.  Since  these  uncertainty  buffers  limit  how  efficiently  the 
airspace  can  be  utilized,  there  is  considerable  benefit  to  be  gained  in  minimizing 
their  sizes. 

Beyond  NAS  Stage  A.  the  concepts  of  Clearance  Directive,  activation  point 
and  clearance  prompt  are  not  incorporated  in  the  NAS  Stage  A  design. 


3.3.2.4  Association  Checking 


As  illustrated  more  explicitly  in  Figure  3-10,  Association  Checking  is  that 
function  which  compares  the  observed  aircraft  tracks  with  the  projected  flight 
trajectories.  Significant  deviations  are  dealt  with  as  follows: 
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Longitudinal  deviations  greater  than  a  specified  error  threshold  result  in 
computed-time-of-arrival  (CTA)  updates  being  projected  along  the  tra¬ 
jectory.  Since  progress  other  than  predicted  along  the  trajectory  can  upset 
strategic  planning,  such  deviations  may  trigger  replanning  depending  on  their 
magnitude  and  their  impact  on  other  trajectories. 

Lateral  deviations  sometime  result  from  navigation  errors  following  a 
planned  courseline.*  Nominal  deviations  are  factored  into  the  protection 
criteria  used  by  the  AERA  algorithms.  However,  excessive  unplanned 
deviations  (blunders)  are  possible.  They  must  be  detected  and  processed.  If  a 
deviation  is  detected  which  exceeds  that  protected  about  the  cleared  route 
centerline,  an  "out  laterally"  alert  is  generated.  "Out  laterally"  alerts  are 
transformed  into  appropriate  messages  by  the  Tactical  Execution  function 
(for  the  pilot  and  any  external  ATC  facility  which  might  be  affected).  They 
are  also  made  available  to  the  Man-Machine  Interface  function  for  possible 
output  to  the  controller(s)  affected  that  are  local  to  this  facility  as  shown  in 
Figure  3-10.  See  the  discussion  in  Section  3.4.6  "Excessive  Deviations  from 
Planned  Profiles". 

Blunder  prediction  is  also  possible  and  might  be  a  desirable  enhancement. 
Such  predictions  would  take  into  account  current  track  speed  and  heading,  given  a 
deviation  which  is  not  yet  a  violation. 

Vertical  deviations  from  the  planned  trajectory  can  also  occur.  When  a  flight 
is  level  at  its  assigned  altitude,  conformance  to  within  a  few  hundred  feet  is 
expected.  When  undergoing  a  transition  to  a  new  altitude  assignment,  the 
deviations  relative  to  the  trajectory's  nominal  vertical  profile  may  be  considerable, 
depending  upon: 

a.  The  degree  of  pilot  discretion  permitted  regarding  pitch  change  points 
and  climb  or  descent  gradients,  as  well  as 


♦Wide  deviations  may  also  be  expected  for  weather  cell  avoidance  and  are 
discussed  under  the  section  de - J  to  "Severe  Weather  Avoidance". 
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b.  The  tolerance  given  to  flight  technical  error  in  navigating  a  prear¬ 
ranged  profile. 

However  relaxed  the  criterion  for  vertical  deviations  from  the  nominal 
profile,  unacceptable  vertical  deviations  must  be  detected  and  protected  against. 
An  aircraft  is  considered  out-of-association  vertically  if  it  exceeds  the  profile 
protection  limits  used  by  the  strategic  planning  function  in  planning  conflict-free 
clearances.  If  an  excessive  deviation  is  detected,  an  "out  vertically"  alert  is 
generated.  "Out  vertically"  alerts  are  transformed  into  appropriate  messages  for 
the  Tactical  Execution  and  Man-Machine  Interface  functions. 

For  an  aircraft  just  beginning  a  transition  along  an  agreed-to  profile,  profile 
deviation  prediction  might  be  possible. 

Clearances  which  are  yet  to  be  issued  to  a  given  flight  are  triggered  by 
activation  points  for  Clearance  Directives  (which  are  defined  subsequently).  When 
the  current  track  of  an  aircraft  is  detected  to  have  reached  an  activation  point 
along  the  flight  trajectory,  a  "clearance  prompt"  is  generated.  This  prompts  the 
tactical  execution  of  the  associated  Clearance  Directive  for  automatically 
generated  and  delivered  messages.  It  may  also  prompt  the  controller  regarding  any 
tasks  for  which  he  is  responsible.  Also  prompted  by  Association  Checking  are  voice 
frequency  changes,  flight  data  transfers  and  transfer-of-control  responsibility 
offers. 

While  it  is  expected  that  all,  or  nearly  all,  aircraft  served  by  AERA  will  be 
equipped  with  altitude-reporting  transponders,  provision  is  made  for  manual  entry 
of  pilot-reported  altitude  and  identity  by  controllers  so  that  track  association  may 
be  maintained  during  the  transition  period  and  in  those  rare  cases  when  the 
airborne  equipment  has  failed. 
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in  NAS  Stage  A,  automatic  association  checking,  exclusive  of  vertical 
association  during  climb  and  descent,  is  performed,  but  with  less  accurate  trajectory 
and  surveillance  data  than  are  expected  to  be  available  in  AERA.  The  controller 
has  to  respond  to  all  "out-of-association"  alerts.  NAS 

Stage  A  automatically  generates  handoff  prompts  where  adapted  but,  since  it 
knows  nothing  of  planned  clearances,  it  cannot  generate  clearance  prompts. 

3.3.2.5  Conflicts  and  Delays  Prediction 

For  any  flight  with  a  newly  planned  or  revised  trajectory,  it  is  necessary  to 
find  all  conflicts  and  any  flight  delays  produced  by  competition  with  the  other 
currently  planned  trajectories.  This  function  is  performed  by  Conflicts,  Delays 
Prediction  shown  in  Figure  3-11.  Since  the  plan  at  any  point  in  time  is  vulnerable 
to  prediction  errors  and  subsequent  events,  periodic  updating  is  required. 

The  flight  whose  trajectory  is  being  submitted  for  conflicts  and  delays 
prediction  is  the  "subject".  The  flights  whose  trajectories  potentially  compete  with 
the  subject  are  the  "objects".  Since  only  a  minority  of  all  the  currently  planned 
trajectories  will  possibly  compete  with  the  subject,  logic  filters,  defined  below,  are 
used  to  reduce  the  set  of  objects  to  a  relevant  subset. 

Conflict  Prediction:  Object  trajectories  which  do  not  come  close  to 
intersecting  are  filtered  out.  Object  trajectories  which  come  close  to  intersecting, 
but  whose  passage  of  the  intersection  is  widely  separated  in  time,  are  filtered  out. 
Only  those  pairs  of  flights  which  are  not  filtered  out  on  these  gross  criteria  are 
subjected  to  conflict  prediction's  "fine  filter". 

The  fine  filter  checks  to  see  whether  horizontal  separation  will  be  lost  with 
high  probability.  If  so,  it  then  checks  to  see  whether  vertical  separation  will  be 
lost  with  high  probability.  If  separation  will  be  lost,  the  conflict  is  declared  "real" 


and  posted  for  resolution  planning.  If  separation  might  be  lost,  but  if  there  will  be 
subsequent  opportunities  to  check  again  before  committing  to  a  final  plan,  no 
conflict  is  declared  on  this  interaction.  But  if  the  time  remaining  to  closest 
approach  requires  resolution  planning  before  the  next  interaction  and  if  there  is 
any  chance  that  the  separation  standard  might  be  violated,  a  conflict  is  declared 
"real".  This  technique  leads  to  a  design  for  a  variably  selective  fine  filter  which 
takes  into  account  the  conflict  geometry,  the  estimated  speeds  of  the  two  aircraft 
and  the  probable  error  in  those  estimates,  the  amount  of  deviation  allowed  in 
following  their  planned  trajectories  and  the  time  remaining  to  closest  approach. 
See  Appendix  4  entitled  "Strategic  Conflict  Prediction  in  AERA". 

AERA  reliably  predicts  conflicts  as  much  as  twenty  minutes  ahead  of  the 
estimated  time  of  closest  approacn  auu  identifies  every  potential  conflict  before 
the  time  to  closest  approach  is  less  than  five  minutes. 

Delays  Prediction:  Flights  which  are  converging  towards  a  common  desti¬ 
nation  may  exceed  the  traffic  handling  capacity  of  that  destination,  be  it  an 
airport  or  downstream  ATC  facility.  Such  saturable  facilities  may  directly,  or 
indirectly  through  a  flow  control  authority,  impose  acceptance  rate  restrictions  in 
any  of  several  forms  (so  many  flights  per  hour,  at  least  x  miles  in  trail,  or  as 
tentative  arrival  schedules  relative  to  specified  fixes  or  boundaries).  Such 
externally  imposed  flow  rate  constraints  are  converted  by  AERA  into  time-ordered 
arrival  queues  relative  to  those  facilities.  At  the  outbound  handoff  fix  for  each 
affected  flight,  the  difference  between  its  desired  arrival  time  and  its  projected 
arrival  time  due  to  traffic  is  its  estimated  delay.  Because  of  the  uncertainties  of 
prediction,  this  estimate  is  discounted  so  as  to  avoid  making  arrivals  unnecessarily 
late.  Early  arrivals  are  acceptable  so  long  as  they  are  within  the  range  of 
downstream  delay  absorption  tools.  The  resulting  discounted  delay  for  each 
affected  aircraft  is  posted  for  delay  absorption  planning.  See  Appendix  5 
entitled  "Strategic  Delay  Prediction  in  AERA." 
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Whenever  a  flow  rate  restriction  is  established  for  a  particular  destination, 
queue  formulation  is  begun.  Flights  are  added  to  the  queue  when  their  flight  plans 
are  first  received.  Any  change  in  that  restriction  will  result  in  queue  schedule 
changes,  thus  triggering  recomputation  of  predicted  delays. 

Other  Planned  Actions:  All  flights,  whether  they  have  conflicts  and  delays  or 
not,  are  generally  transferred  to  a  downstream  ATC  facility  (ARTCC  or  TRACON). 
At  some  time  prior  to  the  calculated  outbound  boundary  crossing  time,  the  stored 
flight  data  must  be  transmitted  to  the  next  facility.  Preliminary  data  may  be  sent 
to  support  initial  planning  by  the  downstream  facility.  More  complete  and 
accurate  data  may  be  sent  later  to  support  full  planning  by  the  downstream 
facility.  The  subsequent  offer  to  transfer  control  responsibility  must  be  made  well 
before  the  flight  actually  crosses  the  boundary.  In  addition,  before  the  flight 
crosses  the  coverage  boundary  between  two  RCAGs,  or  the  control  boundaries 
between  two  sectors,  with  different  frequencies,  a  change-voice-frequency  action 
must  be  taken.  Each  of  these  actions  is  planned  in  advance  and  is  encoded  as 
another  kind  of  activation  point  in  that  flight's  Clearance  Directive  list. 

In  NAS  Stage  A,  an  early  version  of  the  delays  prediction  function  has  been 
specified  as  part  of  the  "en  route  metering"  function  now  under  development. 
Early  versions  of  en  route  metering  have  been  implemented  at  the  Denver  and  Fort 
Worth  ARTCCs.  A  "flight  plan  probe"  function  has  been  specified  as  a  possible 
NAS  enhancement,  but  no  development  of  experimental  NAS  software  has  begun. 

In  both  NAS  Stage  A  and  ARTS,  automatic  data  transfer  and  offers  to 
transfer  control  responsibilities  are  made  to  downstream  sectors  (ARTCC  or 
TRACON),  but  controller  action  is  always  required  for  acceptance  of  track  control 
responsibility.  Change-voice-frequency  instructions  are  not  automated. 
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3.3.2.6  Strategic  Planning  of  Conflict  Resolutions  and  Delay  Absorptions 

Strategic  Planning  involves  two  primary  functions:  the  prediction  of  con¬ 
flicts  and  delays  to  be  dealt  with  by  AERA,  and  the  planning  resolution  and 
absorption  maneuvers  to  be  employed  if  these  problems  persist.  The  result  of  this 
planning  process  is  a  set  of  currently  planned  trajectories  which  are  conflict-free 
and  metered.  Another  kind  of  planning  function,  discussed  later,  is  the  prediction 
of  sector  and  facility  workloads  and  a  predictor  of  expected  traffic  densities.  The 
supervisory  postion  would  be  automatically  notified  of  any  projected  saturations 
and  would  be  provided  with  an  appropriate  range  of  flow  control  actions  from 
which  the  proper  action  and  its  activation  time  could  be  selected. 

As  shown  in  Figure  3-11,  the  strategic  planning  function  has  the  set  of 
currently  planned  flight  trajectories  for  its  input  and  produces  lists  of  planned 
Clearance  Directives  as  its  output,  one  list  for  each  planned  trajectory.  The 
Clearance  Directive  List  for  each  flight  trajectory  is  a  distance-ordered  list  of 
Clearance  Directives.  The  distance  to  each  Clearance  Directive  is  computed  by 
summing  state  segment  lengths  from  the  trajectory's  local  origin  to  the  location  of 
the  Clearance  Directive's  planned  activation  point.  Association  Checking  peri¬ 
odically  notes  the  forward  progress  of  each  track  in  terms  of  its  along-route 
distance  and  compares  that  to  the  distance  of  the  activation  point  for  the  next 
Clearance  Directive.  When  reached,  a  clearance  prompt  is  sent  to  the  Tactical 
Execution  function. 

The  set  of  Clearance  Directive  Lists  constitutes  the  current  clearance  plan 
for  all  flights  in  the  system.  The  Tactical  Execution  function  subsequently 
converts  these  planned  Clearance  Directives  into  the  streams  of  uplink  and 
crosstell  messages  required  to  execute  that  plan.  If  there  is  a  need  for  a  new 
Clearance  Directive,  it  is  fed  back  for  trajectory  remodeling  and  for  checking  to 
ensure  that  the  replanned  trajectory  is  in  fact  conflict-free  and  metered.  As  the 
planned  flights  progress  through  the  system,  trajectories  are  updated  and  conflicts 
and  delays  are  periodically  repredicted.  Significant  changes  trigger  a  reexami¬ 
nation  of  the  Clearance  Directives  planned  for  the  affected  flights. 
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The  Clearance  Directives  in  each  list  are  particular  applications  of  a  family 
of  ATC  procedures.  These  procedures  collectively  represent  all  of  the  tools  in  the 
kit  of  good  ATC  practices.  Such  tools  range  from  generic  tools  of  broad 
applicability  to  very  specific  tools  for  special  applications  (possibly  tailored  to 
each  facility).  Each  is  designed  to  achieve  a  specific  kind  of  tactical  objective.  A 
few  examples  are: 

•  A  vector,  either  a  dogleg  or  a  parallel  offset,  to  pass  behind  or  by 
conflicting  traffic  (one  or  more  aircraft  are  designated  as  traffic  to  be 
avoided  by  the  maneuvering  aircraft). 

•  A  new  altitude  assignment,  with  or  without  pilot  discretion,  as  to  when 
pitch  change  is  to  be  initiated.  Crossing  restrictions  may  be  appended 
to  ensure  that  the  new  altitude  is  achieved  by  a  specified  location,  or 
that  the  altitudes  protected  for  crossing  aircraft  at  particular  locations 
are  avoided  during  the  transition. 

•  A  speed  reduction  to  achieve  a  specified  delay  before  reaching  a  point 
on  the  trajectory. 

•  A  vector  sequence,  either  a  doglog  or  an  S  turn,  computed  to  achieve  a 
specified  delay  before  reaching  a  point  of  the  trajectory. 

Clearance  Directives  can  be  adapted  for  use  with  aircraft  that  are  RNAV 
equipped.  The  flight  plans  of  such  aircraft  would  indicate  the  proper  equipment 
qualifier. 

Clearance  Directives  would  also  be  used  to  plan  and  effect  the  transfers  of 
flight  data  and  flight  control  to  a  downstream  sector  or  facility.  The  transfer-of- 
control  directive  transmits  an  offer  to  transfer  traffic  control  responsibility,  and  if 
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the  offer  is  accepted,  transmits  a  message  to  the  transferred  flight,  instructing  it 
to  "contact  ATC"  on  the  next  sector's  voice  frequency  (ARTCC  or  TRACON).  In  a 
DABS  environment,  this  process  may  be  automated  so  that  pilot  and  controller  may 
not  have  to  be  involved  in  the  process  of  changing  frequencies,  but  the  estab¬ 
lishment  of  communication  on  the  new  frequency  must  be  verified.  If  the  next 
facility  is  an  airport  traffic  control  tower,  the  flight  is  instructed  to  contact  the 
tower  on  the  tower's  voice  frequency  and  AERA  level  service  is  terminated. 

Conflict  resolution  is  a  function  within  the  Resolution  and  Absorption 
Planning  (Figure  3-11).  It  starts  with  two  (or  more)  flights  predicted  to  be  in 
potential  conflict  with  each  other  after  all  filtering  processes  described  earlier. 
Conflict  resolution  must  decides 

•  Which  aircraft  is  to  be  treated  as  "privileged",  therefore  possessing  the 
right-of-way,  and  which  is  to  be  treated  as  "burdened",  therefore  having 
to  yield  the  right-of-way. 

•  Which  resolution  is  to  be  preferred  in  resolving  the  conflict.  This  can 
depend  on  whether  the  burdened  aircraft  is  currently  at  its  desired 
altitude  or  not,  or  whether  the  burdened  aircraft  is  coming  up  on  a 
change  in  course  or  altitude  as  part  of  its  planned  trajectory. 

•  If  the  preferred  resolution  does  not  solve  the  problem,  the  next  best 
resolution  is  tried  in  the  adapted  hierarchy  of  alternatives  until  a 
workable  one  is  found. 

The  tactic  selected  to  resolve  the  conflict  is  expressed  in  terms  of  a 
particular  Clearance  Directive,  with  the  parameter  values  of  that  directive 
computed  from  specific  information  concerning  the  capability  and  tracks  of  the 
aircraft  involved  in  the  potential  conflict. 
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Delay  resolution  starts  with  the  delay  predicted  for  the  subject  aircraft, 
discounted  so  that  the  likelihood  of  over-estimation  of  delay  is  small.  The  most 
fuel  efficient  method  (speed  reduction)  is  tried  first;  the  least  fuel  efficient 
method  (holding)  is  employed  only  when  the  range  or  more  efficient  tools  are 
inadequate  to  absorb  the  discounted  delay.  Fuel-absorbing  vectors  are  usually 
reserved  for  absorption  of  any  residual  delays  shortly  before  the  outbound  handoff 
point  or  clearance  limit  is  reached. 

The  delay  absorption  strategy  selected  is  expressed  in  terms  of  one  or  more 
delay  absorption  tactics,  one  Clearance  Directive  for  each  tactic,  with  the 
parameter  values  of  each  directive  computed  from  the  amount  of  delay  to  be 
absorbed  and  the  airspace  available  for  its  absorption. 

Exceptions  to  any  predefined  strategic  planning  logic,  however  sophisticated, 
are  to  be  expected.  For  example,  pilots  will  ask  for  special  treatment,  especially 
in  emergencies.  If  an  exceptional  request*  is  made  to  the  AERA  system,  the 
computer  would  refer  such  a  request  to  the  cognizant  sector  controller.  Whether 
the  request  is  referred  to  the  controller  by  the  computer,  or  whether  it  is  made 
directly  to  the  controller  via  voice  radio  or  the  down-link,  the  controller  has  the 
task  of  responding  to  the  request.  Controllers  need  to  have  access  to  all  the 
displays  and  tools  necessary  to  deal  with  these  requests,  such  as  ability  to  review, 
interactively  modify  or  override  computer-planned  solutions. 

In  NAS  Stage  A,  clearance  planning  and  its  execution  in  terms  of  instructions 
to  pilots  and  coordination  with  other  controllers  is  done  manually  by  the  flight  data 
(D)  and  radar  (R)  controllers  at  the  various  sector  positions.  It  is  in  the  automated 
strategic  planning  and  coordination  of  clearances,  and  in  the  automated  tactical 
execution  of  that  plan,  that  the  AERA  concept  goes  beyond  any  capability  found  in 
the  NAS  Stage  A  computer  system. 


*An  exceptional  request  is  one  which  is  outside  the  bounds  of  normal  handling 
rules,  is  unintelligible  to  the  program,  or  which  requests  emergency  handling. 
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3.3.2 .7  Tactical  Execution  of  Plan 

The  lists  of  currently  planned  Clearance  Directives  for  ail  flights  are 
presented  to  the  Tactical  Execution  function  as  shown  in  Figure  3-11.  They 
represent  an  agenda  of  control  and  coordination  messages  to  be  generated  as 
illustrated  in  Figure  3-12.  As  each  flight  track  reaches  the  next  activation  point, 
the  association  checking  function  issues  a  clearance  prompt  for  tactical  execution 
to  begin.  Tactical  Execution  begins  monitoring  the  relative  progress  of  the 
specific  aircraft  tracks  involved  and  generates  the  necessary  control  actions.  As 
the  encounter  situation  develops,  computations  are  made  for  the  type,  content  and 
timing  of  the  messages  to  be  issued.  These  messages  may  be  directed  to  one  or 
more  of  the  flights  involved  or  to  a  downstream  ATC  sector  or  facility.  The 
cognizant  local  sector  is  kept  advised  of  all  activities  and  is  prompted  when  any 
local  action  is  required. 

Each  Clearance  Directive  states  an  explicit  tactical  objective  to  be  met  by 
this  flight.  The  tactical  solution  must  satisfy  any  constraints  established  by 
conflict  resolution  planning,  delay  absorption  planning,  or  an  AERA  sector  con¬ 
troller  who  has  interactively  modified  a  trajectory.  Each  Clearance  Directive  can 
lead  to  no  message  or  can  result  in  the  delivery  of  several  messages.  If  the 
problem  found  and  solved  by  the  planning  function  has  disappeared  by  the  time  the 
tactical  execution  function  compares  the  tracks  of  the  aircraft  involved  against 
the  stated  tactical  objective,  no  message  is  generated.  If,  for  example,  the 
Clearance  Directive  is  to  pass  the  burdened  aircraft  safely  behind  specified 
privileged  traffic,  several  clearances  may  be  generated.  The  first  clearance 
generated  might  call  for  a  shallow  left  turn;  subsequent  clearances  issued  after  the 
aircraft  are  seen  to  have  safely  passed  each  other  might  call  for  course  modifi¬ 
cations  to  resume  a  normal  trajectory. 


AUTOMATED  TACTICAL  EXECUTION  AND  SEPARATION  ASSURANCE 
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Tactical  Execution  is  concerned  with  transforming  the  lists  of  outstanding 
Clearance  Directives  into  up-link  and  crosstell  messages.  However,  an  occasional 
aircraft  may  be  found  to  be  deviating  significantly  from  its  planned  trajectory,  or 
two  (or  more)  aircraft  may  be  found  converging  on  a  potential  separation  violation, 
and  the  resulting  "out-of-association  alert”  or  "conflict  alerts"  must  be  dealt  with 
immediately.  Tactical  Execution  recognizes  the  relative  priority  of  each  type  of 
input  and  deals  with  it  accordingly.  Out-of-association  alerts  are  generated  by  the 
Association  Checking  function,  while  conflict  alerts  are  generated  by  the 
Separation  Assurance  Monitoring  function,  discussed  later. 

Beyond  NAS  Stage  A:  There  is  no  automated  equivalent  of  this  function  in 
NAS  Stage  A.  In  NAS,  the  "Radar"  or  "R"  controller  must  mentally  perform  the 
functions  of  clearance  planning  and  tactical  execution.  He  performs  these 
functions  based  on  his  knowledge  of  flight  intent  (derived  from  posted  flight  strip 
data  and  from  clearances  previously  issued)  and  of  relative  flight  progress  (derived 
from  watching  the  scan-by-scan  progress  of  tracked  aircraft  under  his  control).  He 
executes  his  plan  by  coordinating  planned  clearances  with  other  affected  sector 
controllers  by  voice,  as  necessary,  and  by  issuing  those  clearances  by  voice  to  the 
affected  pilots  at  the  proper  time.  In  most  cases  AERA  performs  all  these 
functions  automatically. 

3.3.2.8  Separation  Assurance  and  Obstacle  Avoidance  Monitoring 

Separation  Assurance  Monitoring  is  performed  on  a  scan-by-scan  basis  and  on 
all  aircraft  tracks,  whether  controlled  or  not.  The  objective  is  to  see  that  (a)  all 
tracked  and  controlled  aircraft  pass  each  other  safely;  and  that  (b)  any  uncon¬ 
trolled  tracks  are  safely  avoided.  Priority  alerts  are  generated  to  the  Tactical 
Execution  function,  and  for  the  cognizant  sector  controller,  whenever  a  potentially 
unsafe  encounter  is  detected.  Ideally,  this  function  should  operate  independently 
of  the  Strategic  Planning  and  Tactical  Execution  functions,  so  as  not  to  mix  what  is 
planned  to  happen  with  what  is  happening. 
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In  NAS  Stage  A,  conflict  alerts  are  generated  by  the  computer  as  a  means  of 
backing  up  controller  detection  and  resolution  of  conflicts.  In  NAS  and  AERA,  the 
effectiveness  of  this  function  is  expected  to  be  enhanced  through  the  use  of  DABS- 
derived  tracks.  The  use  of  the  Tactical  Execution  function  to  generate  instructions 
to  solve  the  problem  identified  by  the  separation  assurance  monitor  does  auto¬ 
matically  what  the  controller  must  accomplish  manually  in  NAS  in  a  time-critical 
manner. 

3.3.3  AERA  Outputs 

3.3.3.1  Ground-to-Air  Communications 

Ground-to-air  data  linked  communications  can  be  used  to  the  extent  that 
flights  are  equipped  to  receive  data  linked  clearances,  including  real-time  control 
instructions,  traffic  advisories  and  other  information  messages.  Controller 
initiated  messages  can  also  be  issued  via  the  data  link. 

Several  additional  ground-based  services  become  available  for  those  aircraft 
equipped  with  data  link  and  airborne  computers.  For  example,  an  airborne 
computer  might  be  used  to  query  the  AERA  computer  regarding  down-route  winds 
aloft,  NOT  AMS  or  other  data  valuable  to  in-flight  planning.  If  Cockpit  Displays  of 
Traffic  Information  (CDTI)  are  installed  as  an  optional  cockpit  feature,  or  as  a 
supplemental  tool  for  air  traffic  control,  the  AERA  computer  can  be  a  major 
source  of  the  data  displayed. 

To  the  extent  that  aircraft  are  not  equipped  to  receive  up-linked  data,  voice 
radio  will  continue  to  be  used.  Either  computer  voice  or  controller  voice  can  be 
employed  to  transmit  computer-generated  messages  over  the  sector  voice 
frequency. 
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3.3.3.2  Other  On-Line  Data  Outputs 

Other  on-line  data  outputs  by  the  AERA  system  are  directed  to  local 
consumers  (e.g.,  Man-Machine  Interfaces)  and  external  facilities  (e.g.,  neighboring 
ARTCCs,  served  TRACONs  and  Towers,  CFCF,  center  area  FSS  and  DABS  sites 
providing  uplink  data  coverage).  Messages  to  upstream  ATC  facilities  (CFCF  and 
feeding  ATC  facilities)  include  flow  restriction  requests,  coordinated  restrictions, 
acknowledgements  of  forwarded  flight  plan  or  track  data  and  acceptances  of 
transfer-of-control  offers.  Messages  to  downstream  facilities  will  include  res¬ 
ponses  to  flow  restriction  requests,  acknowlegements  of  coordinated  restrictions 
received,  forwarded  flight  plan  or  track  data,  and  offers  to  transfer  control 
responsibility  for  specific  flights. 

The  Man-Machine  Interface  function  provides  the  output  tools  necessary  for 
supervisors  and  air  traffic  controllers  to  keep  current  relative  to  their  assigned 
responsibilities;  to  make  planning,  control  or  data  entries;  and  to  receive  messages 
directed  to  them  by  (or  via)  the  AERA  computer  system.  Outputs  to  help  these 
specialists  keep  current  include  displays  of  the  current  airspace  situation  (traffic, 
weather,  etc.)  and  the  state  of  the  system;  also  selected  predicted  future  flight 
trajectories  and  their  possible  interactions,  based  on  current  data.  Other  planning 
aids  would  include  predicted  states  of  the  system  regarding  projected  demands, 
resource  availability  and  possible  saturation  conditions.  Outputs  to  support 
planning,  control  and  data  entries  include  linked  menus  of  possible  inputs,  input 
message  preview  areas  and  message  editing  tools,  and  quick  responses  to  errored  or 
illegal  entries. 

Messages  directed  to  controllers  from  (or  via)  the  AERA  system  include 
prompts  or  alerts  requested  by  the  controller,  requests  for  a  specific  data  item  or 
decision,  data  on  exceptional  situations  which  are  to  be  brought  to  the  controller's 
attention,  and  data  messages  addressed  from  some  other  service  to  the  controller's 
or  supervisor's  attention. 
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3.3.3.3  Capacity,  Demand  and  Performance  Monitoring 

There  are  basically  two  ways  of  dealing  with  pending  overloads  within  the 
ARTCCs  (a)  decombining  sectors  (adding  sector  teams)  and  putting  additional 
computing  power  on-linej  and  (b)  imposing  flow,  route  or  altitude  restrictions  in 
route,  altitude  or  flow  rate.  To  the  extent  that  such  problems  can  be  predicted  in 
advance,  based  on  the  loads  implied  by  known  trajectories,  pending  flight  plans  or 
flight  schedules,  resource  allocation  can  be  tuned  to  the  projected  demand.  To  the 
extent  that  unpredictable  demands  (perturbations)  must  be  handled,  extra  capacity 
must  be  provided  or  traffic  demand  must  be  diverted.  Such  demands  may  show 
temporary  peaks.  For  example,  the  passage  of  a  weather  front  might  cause  a 
reduction  in  airport  acceptance  rates  and  thus  holding  or  diversions  to  alternate 
airports,  while  at  the  same  time  there  is  an  influx  of  airfiles  from  flights 
converting  from  visual  to  instrument  flight  rules. 

AERA  will  make  en  route  sector  load  demand  and  capacity  predictions, 
prepare  reports  of  current  system  status  and  provide  the  necessary  displays  and 
interactive  tools  for  facility  supervisors  and  sector  controllers  to  handle  these 
perturbations  to  normal  demands. 
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4.0  AERA  System  Integrity 

The  AERA  system  concept  takes  into  account  both  those  internal  failures  and 
external  occurrences  which  disrupt  AERA's  ability  to  provide  its  services.  These 
events*  whether  internal  or  external,  are  referred  to  as  system  perturbations. 

There  is  a  wide  spectrum  of  potential  internal  and  external  system  pertur¬ 
bations  due  to  a  great  variety  of  causes.  This  requires  a  broad  strategy  to 
counteract  the  consequences  of  all  identifiable  perturbations,  and  great  care  to 
assure  that  ail  possible  perturbations  are  identified.  However,  the  strategy 
selected  to  provide  reliability,  does  maintain  safety  even  if  the  cause  of  a 
perturbation  had  not  been  previously  identified.  Finally,  AERA  is  designed  so  that 
ATC  will  survive  even  catastrophic  failures,  for  example,  a  complete  center 
outage. 

The  required  robustness  of  ATC,  despite  perturbations,  places  some  general 
functional  requirements  on  the  design  for  AERA  system  integrity: 

1.  No  AERA  failure  can  put  an  aircraft  at  hazard. 

2.  No  AERA  failure  can  place  a  pilot  or  controller  in  a  position  where  he 
cannot  fulfill  his  responsibilities. 

3.  AERA's  inherent  total  failure  rate  must  be  minimized.  (Representative 
objectives  are  that  less  than  one  outage  of  an  ARTCC  per  20  years 
should  be  achievable  and  this  outage  should  not  last  longer  than  one 
hour.)  (Backup  modes  of  operation  during  failure  are  discussed  in 
Section  4.3.) 
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4.  AERA  must  be  able  to  recognize  service  failures  before  hazards  to 
controlled  aircraft  can  develop. 

5.  The  AERA  concept  does  provide  for  recovery  from  failures  by  auto¬ 
matically  or  semi-automatically  reconfiguring  with  spare  capacity. 

6.  AERA's  restoration  to  full  capability  after  a  failure  must  be  preplanned 
and  expeditious. 

Fortunately,  these  requirements  on  AERA  can  be  satisfied  despite  the  fact  that 
failures  may  limit  the  flow  of  traffic. 

The  AERA  concept  is  designed  to  accommodate  specific  kinds  of  failures,  for 
example: 

a.  Tower,  TRACON  or  Center  total  or  partial  failure 

b.  DABS/ATCRBS  site 

c.  VHF  communication  facility 

d.  VOR/DME  site 

e.  Aircraft  DABS/ATCRBS,  VHF,  or  navigation  systems 

However,  the  AERA  concept  is  not  designed  to  accommodate  multiple  failures  of 
contiguous  FAA  facilities,  for  example,  two  adjoining  Centers.  The  probability  of 
the  simultaneous  failure  of  two  major  adjoining  facilities  is  considered  to  be  so 
small,  and  the  cost  of  designing  a  system  that  would  be  proof  against  such 
simultaneous  failures  so  large,  that  it  is  not  practical  to  have  the  AERA  concept 
deal  with  this  case. 
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Section  4.1  presents  a  general  model  of  the  AERA  recovery  process  which  is 
a  useful  framework  for  describing  various  options.  The  approaches  for  achieving 
reliability  within  AERA  are  described  in  Section  4.2.  Finally,  Section  4.3  describes 
the  more  obvious  AERA  perturbations  and  failure  modes  and  various  options  to 
recover  from  these  perturbations. 

4.1  General  Model  of  AERA  Recovery  Process 

There  is  a  general  model  of  the  AERA  system's  response  to  perturbations  as 
depicted  in  Figure  4-1.  The  model  postulates  a  number  of  illustrative  AERA  states 
and  recovery  processes  which  may  be  invoked  after  a  failure.  AERA  operation,  as 
described  in  Section  3,  is  considered  the  nominal  state.  An  example  of  a 
perturbation  to  the  nominal  state  is  a  failure  in  a  single  processor  which  places 
AERA  in  a  disturbed  state.  The  detection  of  the  failure  and  its  automatic 
replacement  with  a  redundant  processor  is  the  stabilizing  process.  AERA  is  in  a 
stabilized  state  when  the  redundant  processor  is  on-line  and  the  failed  processor  is 
off-line.  The  normalizing  process,  in  this  case,  involves  the  replacement  of  the 
failed  off-line  processor  with  a  working  processor,  so  that  AERA  would  have  its 
normal  complement  of  redundant  processors  and,  therefore,  be  restored  to  its 
nominal  state.  This  simple  example  of  a  failure  did  not  impact,  as  it  must  not, 
safety  of  aircraft,  or  the  traffic  handling  capacity  of  AERA.  However,  more 
substantial  failures,  such  as  total  computer  system  failure  or  a  catastrophe  to  an 
ARTCC,  would  require  a  stabilizing  process  that  would  assure  the  safety  of 
aircraft  under  the  jurisdiction  of  that  ARTCC,  and  undoubtedly  a  limitation  of 
traffic  flow  into  the  jurisdiction  of  the  ARTCC  commensurate  with  its  or  the  ATC 
system's  surviving  capabilities.  The  value  of  the  model  shown  in  Figure  4-1  is  that 
it  makes  explicit  the  various  recovery  processes  and  capabilities  of  AERA  from 
first  detection  of  a  failure  to  complete  restoration  of  the  original  capabilities  of 
AERA. 


PERTURBATION 


ERA  PLANNING  REGION  STATE  CYCLE 
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4.2  Approaches  to  Achieving  Reliability  Within  AERA 

Many  levels  of  redundancy  and  contingency  planning  are  needed  in  order  to 
meet  the  reliability  requirements  defined  in  Section  4.0,  both  within  AERA  and  the 
ATC  system,  in  which  AERA  is  imbedded.  This  section  discusses  approaches  to 
improving  the  integrity  of  AERA  itself.  The  strategies  for  dealing  with  the  great 
variety  of  possible  internal  and  external  perturbations  are  described  in  Section  4.3. 

4.2.1  Appropriate  Design  Concepts 

The  following  design  concepts  enhance  AERA  integrity. 

•  Modularize  Functions;  Use  multiple  computers,  each  supporting  one  or 
at  most  a  few  AERA  processing  functions.  In  effect,  any  failures  are 
modularized,  so  they  cannot  violate  the  functional  partitions.  This 
modularization  process  should  include: 

•  Use  of  Small  Partitions:  Implementing  fewer  functions  per  , 
computer  leads  to  reducing  the  impact  on  the  center  of  any  given 
computer  outage.  It  also  provides  quicker  recovery  and  less 
complicated  checking  and  testing  procedures. 

•  Provision  of  Functional  Independence:  Unrelated  programs  should 
not  be  grouped  together  in  the  same  computer  hardware.  For 
example,  a  failure  in  a  flight  plan  processor  should  not  affect  a 
radar  target/track  processor,  and  vice  versa. 

•  Provide  Modular  Redundancy:  All  processors  supporting  AERA  critical 
functions  should  be  backed  up  by  redundant  processors.  The  number  of 
redundant  processors  for  each  on-line  unit  should  range  from  a  fraction 
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(perhaps  one  backup  per  three  operational  processors)  for  less  important 
tasks,  to  several  for  the  more  critical  functions.  Since  any  given 
processor  will  be  supplying  data  to  certain  other  processors  at  a  higher 
level  of  data  integration,  its  failure  will  degrade,  if  not  destroy,  the 
functions  performed  by  other  processors.  Failure  of  a  processor  must 
be  recognized  and  backup  processors  activated  rapidly.  This  modular 
redundancy  should  entail: 

•  Use  of  Parallel  Processing  for  Key  Functions?  Real-time  validity 
checking  by  parallel  processing  can  significantly  reduce  the 
effects  of  AERA  system  failures  by  providing  an  immediate 
system  and  subsystem  backup. 

•  Implement  Hardware  and  Software  Performance  Monitors:  Perfor¬ 
mance  monitors,  alarms  and  automatic  redeployment  of  assets  should 
be  provided.  Performance  monitors  can  take  the  form  of  hardware 
devices  which  measure  CPU  activity  or  the  inclusion  of  software 
structures  which  record  internal  computer  clock  time  at  the  start  and 
end  procedure.  They  can  take  the  more  specific  form  of  test  problems 
that  broadly  evaluate  the  performance  of  each  processor  periodically. 

•  Use  High  Reliability  System  Control  Techniques:  At  some  point  any 
decision  process  converges  to  a  single  point.  The  design  should  be  such 
that  this  convergent  point  uses  highly  reliable  technology.  The  present 
NAS-9020  computer  system  and  most  other  multi-processor  instal¬ 
lations  are  designed  with  a  software  executive  to  provide  coherent 
operational  control.  For  AERA,  techniques  should  be  selected  that  do 
not  allow  failure  of  the  executive  to  cause  complete  system  outages. 
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Use  High  Reliability  Software  Techniques:  State  of  the  art  source 
language,  coding  techniques,  and  general  software  design  procedures 
should  be  employed  to  ensure  reliable  software  implementation.  The 
techniques  includes 

•  Screening  Incoming  Data  for  Consistency,  Content  and  Range: 
Each  software  function  should  include  program  segments  which 
validate  the  incoming  data  within  known  limits  or  values.  This 
will  limit  output  errors. 

•  Minimizing  Single  Point  Dependencies:  Use  diverse  routes  for  the 
flow  of  data  and  system  control  codes  through  the  system,  and 
non-singular  functional  dependencies,  such  that  no  single-point 
failure  can  cause  the  system  to  fail. 

•  Using  Computational  Checking  Techniques:  This  can  be  accom¬ 
plished,  for  example,  by  multiple  independent  algorithms,  by 
simultaneous  computation  in  different  processors,  or  by  a  com¬ 
bination  of  these  techniques.  Voting  on  widely  discrepant  results 
or  averaging  of  similar  results  can  then  be  used  to  reach  a  final 
solution. 

Include  Error  Detection  and  Self -Test  Hardware  and  Software:  The 
AERA  computers  should  be  equipped  with  error  detection  capabilities 
for  memory  or  peripheral  read/write  transactions,  and  self-test  hard¬ 
ware  and  diagnostic  software.  These  features  often  make  it  possible  to 
trap  failing  computers  and  transfer  them  off-line  before  they  have 
actually  failed  to  perform  the  specified  functions. 
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•  Provide  Real-Time  Validity  Checking:  For  critical  AERA  functions, 
the  validity  of  output  results  should  be  checked  continuously  for  reason¬ 
ableness  ,  either  manually  or  automatically. 

•  Incorporate  Independent  Checks  of  AERA  Outputs:  For  example, 
ATARS  track  files  could  be  compared  periodically  with  those  used  to 
predict  conflicts  within  AERA. 

Appendix  6  describes  a  computer  architecture  that  meets  the  integrity 
requirements  defined  in  Section  4.0  and  fits  the  AERA  concept. 

4.3  Perturbation  or  Failure  Modes  and  Recovery  Concepts 

There  is  a  great  variety  of  perturbation  or  failure  modes  that  AERA  is 
designed  to  resist.  There  is  also  a  great  variety  of  recovery  options  designed  to 
handle  each  perturbation.  The  minimum  recovery  option  for  each  perturbation  is 
one  that  maintains  a  satisfactory  level  of  aircraft  safety.  More  elaborate  recovery 
options  can  provide  improved  levels  of  aircraft  safety  during  recovery,  or  can 
provide  increased  traffic  flow  before  total  recovery  to  the  nominal  state  of  AERA. 
These  more  elaborate  recovery  options  are  more  expensive,  but  they  also  provide 
more  capability.  Cost-effectiveness  issues  will  ultimately  determine  the  extent  to 
which  the  more  elaborate  recovery  options  are  implemented.  However,  it  is 
essential  to  implement  the  minimum  recovery  concept,  that  maintains  safety 
during  the  period  of  any  perturbation  and  the  recovery  period. 

4.3.1  Total  Loss  of  an  ARTCC 


The  most  drastic  failure  that  could  beset  AERA  would  be  the  total  loss  of  an 
ARTCC  and  its  AERA  capability  with  no  surviving  communication,  surveillance  or 
flight  plan  processing  capability  at  the  affected  center.  Current  FAA  directives 
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provide  that  individual  facilities  shall  develop  and  maintain  operational  plans  to 
provide  continuity  of  service  in  the  event  of  such  emergencies.  These  plans  are 
developed  on  a  local  level  and,  in  the  case  of  en  route  facilities,  will  generally 
provide  for  redelegation  of  facility  airspace  to  adjacent  en  route  facilities  and 
underlying  terminals  in  the  event  the  parent  facility  is  lost. 

Although  reasonable  in  concept,  the  current  approach  to  backup  has  flaws. 
Primary  among  these  is  that  the  parent  facility  is  not  continuously  sharing  flight 
plan  information  and  clearance  information  with  backup  facilities  on  all  flights  in 
the  parent  facility's  airspace,  and  that  backup  facilities,  in  some  cases,  do  not  have 
surveillance  and/or  communications  coverage  for  all  of  the  redelegated  airspace. 
Lack  of  backup  facility  controller  knowledge  of  airspace  areas  to  be  assumed  is 
another  problem.  Inasmuch  as  the  total  loss  of  an  en  route  facility  is  a  very  low 
probability  event,  these  flaws  have  been  tolerated.  Major  failures  of  facilities, 
however,  have  occurred  and,  according  to  observers,  the  initial  stabilization  of  the 
traffic  situation  was  chaotic  and  reinstitution  of  reasonable  levels  of  air  traffic 
service  was  problematic.  Some  of  these  deficiencies  could  be  partially  alleviated 
in  the  current  NAS  system,  however  nothing  as  robust  as  the  backup  clearance 
concept  of  AERA  is  possible  because  of  the  required  global  planning  capability. 

Minimum  Recovery  Concept:  In  developing  a  concept  for  recovery  from  such 
a  catastrophic  failure,  a  guiding  principle  is  that  the  system  must  be  stabilized 
automatically  and  without  dependency  on  controller  intervention.  The  period  of 
stabilization  is  one  which  is  most  chaotic  for  the  affected  and  adjacent  centers. 
Controllers  could  not  be  expected  to  organize  a  stabilizing  process  in  time  to 
assure  safety.  Furthermore,  since  the  controller,  in  this  minimum  recovery  option, 
performs  the  control  function  in  the  reconfigured  state,  the  stabilizing  process 
must  automatically  reduce  traffic  densities  and  flows  to  a  level  that  can  be 
controlled  manually.  In  many  control  facilities  there  are  overlapping  communi¬ 
cation  and  surveillance  coverages  with  neighboring  facilities  and  the  exchange  of 
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flight  plan  information,  as  well  as  supporting  automation  and  display  capabilities. 
In  such  cases,  the  controller  in  the  backup  facility  does  not  have  to  rely  on 
procedural  techniques,  and  uses  the  tools  available  to  him.  However,  the  minimum 
recovery  concept  works  even  when  the  only  tools  he  has  are  a  list  of  backup 
clearances  and  communication  with  the  aircraft  responding  to  these  clearances. 

To  accomplish  the  objectives  of  this  minimum  recovery  option,  AERA  is 
designed  to  plan  and  update  "backup"  clearances.  These  clearances  are  transmitted 
to  DABS  and  communication  sites,  stored  there  in  buffers,  and  are  sent  auto¬ 
matically  to  those  aircraft  that  were  under  the  jurisdiction  of  the  ARTCC  when 
that  center  is  judged  to  have  failed.  This  judgment  may  be  manual  or  automatic, 
depending  on  the  level  of  diagnostics  in  AERA  and  the  details  of  this  failure  mode. 
Alternatively,  the  backup  clearances  could  be  continuously  transmitted  to  buffers 
located  at  the  backup  facilities,  to  be  automatically  transmitted  to  aircraft  in  case 
of  center  failure. 

The  functional  form  of  the  backup  clearance  varies  for  each  aircraft: 

a.  If  an  aircraft  can  safely  proceed  to  an  adjacent  nonfailed  airspace 
region  under  its  current  clearance,  it  is  cleared  to  do  so.  Note  that  no 
AERA  automatic  clearance  can  be  delivered  along  the  remainder  of  its 
route. 

b.  Aircraft  that  might  conflict  in  future  time  along  their  current  route 
receive  a  backup  clearance  to  essentially  hoid-in-piace,  if  it  is  possible 
to  safely  execute  such  a  clearance.  The  clearance  must  not  result  in  a 
holding  pattern  which  overlaps  that  of  another  aircraft. 

c.  If  hold-in-place  is  not  possible,  special  logic  is  used  to  layout  an 
appropriate,  more  complicated  clearance  ("Proceed  direct  XXX,  Hold"). 
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The  traffic  holding  in  the  failed  airspace  is  then  "drained"  using,  for  each 
aircraft,  procedural  control  from  the  designated  emergency  facility.  Since  the 
airspace  situation  was  stabilized  and  there  are  fairly  large  time  buffers  available 
(e.g.,  minimum  IFR  holding  reserves  of  45  minutes),  the  controllers  are  not 
presented  with  an  unmanageable  workload  peak. 

One  or  more  backup  facilities  have  to  be  designated,  whether  they  are 
adjacent  centers  or  underlying  TRACONs.  These  facilities  have  to  have  surviving 
links  with  the  communication  facilities  that  served  the  jurisdiction  of  the  failed 
ARTCC  or  alternate  communication  coverage,  and  have  to  have  the  list  of  the 
backup  clearances  that  have  been  issued.  Each  must  have  the  list  of  backup 
clearances  appropriate  for  its  region  and  a  surviving  communication  capability  for 
aircraft  in  its  assigned  region.  With  this  information  and  communication  capa¬ 
bility,  the  designated  backup  facilities  can  excerise  control  over  the  aircraft  that 
remain.  Radar  control  and  flight  plan  processing  would  obviously  be  utilized  in 
these  backup  facilities  that  have  the  needed  surveillance  coverage  and  processors. 

If  the  center  is  not  totally  destroyed  and  if  communications  with  the  affected 
aircraft  can  be  maintained  or  reestablished  from  the  ARTCC,  then  the  backup 
responsibility  might  remain  at  the  failed  ARTCC,  a  subject  discussed  more  fully  in 
Section  4.3.2.  It  would  also  be  necessary  that  a  record  of  the  transmitted  backup 
clearances  survive  at  the  ARTCC.  Maintaining  the  emergency  facility  at  the 
failed  ARTCC  has  the  advantage  of  utilizing  controllers  who  are  familiar  with  the 
situation  when  draining  the  airspace. 

While  there  has  been  only  a  preliminary  analysis  of  the  backup  clearance 
concept*,  it  seems  that  no  more  than  5  percent  to  12  percent  of  the  aircraft  will 
need  a  clearance  requiring  extensive  flying  to  an  available  holding  area.  Thus,  the 
need  for  backup  clearances  should  not  place  an  unreasonable  additional  load  on  the 
computational  capability  of  AERA,  Furthermore,  when  one  segregates  traffic  into 

•"Feasibility  of  the  AERA  Backup  Clearance  Concept,"  MITRE  WP-80W00588, 
July  1980. 
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categories,  such  as  overflight  or  transitioning  to  arrival  or  from  departure 
airspace,  it  seems  that  approximately  50  percent  of  the  traffic  can  be  drained  by 
safely  proceeding  to  nonfailed  airspace  regions  controlled  by  neighboring  ARTCCs 
or  underlying  TRACONs  —  particularly  if  these  regions  can  extend  their  responsi¬ 
bility  to  the  limits  of  their  surveillance  and  communication  coverage  as  part  of  the 
stabilizing  process.  The  surveillance  and  communication  coverage  of  ARTCCs  and 
TRACONs  extends  beyond  their  control  region.  The  remaining  aircraft  should  be 
capable  of  being  safely  conducted  from  the  affected  airspace  by  procedural  control 
exerted  from  the  emergency  facility. 

Whenever  backup  clearances  are  released,  departure  and  hand-off  restrictions 
are  transmitted  automatically  to  all  control  regions  adjoining  the  affected  region. 
Subsequent  to  the  stabilization  of  the  affected  region,  the  level  of  traffic  is 
limited  by  the  surviving  communication,  surveillance  and  control  facilities  serving 
the  region. 

While  this  minimum  recovery  option  and  AERA  itself  does  not  depend  on  the 
implementation  of  DABS/ATARS,  BCAS  and  CDTI,  the  recovery  process  could  be 
enhanced  if  DABS  were  implemented  and  aircraft  were  equipped  with  BCAS  and 
CDTI.  For  example,  DABS  sites  may  be  instructed  to  provide  an  expanded  type  of 
ATARS  service  giving  early  warning  of  potential  conflicts  and  appropriate 
resolution  advisories,  as  a  part  of  the  Minimum  Recovery  Concept. 

Higher  Investment  Recovery  Options 

In  all  options  to  be  discussed,  the  stabilizing  process  utilizes  the  backup 
clearance  stabilization  concept,  as  described  in  the  previous  section.  As  will  be 
shown,  the  major  differences  among  the  options  are  the  nature  of  the  recuperative 
process,  the  time  to  reconfigure  and  the  level  of  service  obtained  in  the  affected 
AERA  planning  region  in  the  reconfigured  state. 
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Option  1;  Both  communication  and  surveillance  sites  are  dual-connected  to 
the  designated  emergency  facilities,  as  well  as  to  the  ARTCC  that  they 
normally  serve.  Remoted  communication  and  surveillance  would  then  be 
provided  to  the  appropriate  boundary  sectors.  The  communication  and 
surveillance  information  could  be  provided  to  spare  displays,  such  as  exist  in 
training  labs.  This  would  allow  the  opening  of  sectors  dedicated  to  the 
assumed  area  in  the  event  that  the  outage  became  lengthy.  However,  only 
procedural  control,  augmented  with  surveillance,  could  be  exerted  initially. 
The  controllers  would  have  to  poll  aircraft  in  their  sectors  to  gather  flight 
plan  information  before  they  could  provide  the  most  effective  service.  This 
increases  the  duration  of  the  recuperative  process  as  compared  to  more 
elaborate  recovery  options. 

Option  2:  In  addition  to  the  emergency  facilities'  responsibilities  and 
capabilities,  as  described  in  Option  1,  current  flight  data  and  clearance  plans 
for  aircraft  in  the  AERA  control  region,  would  be  continuously  transmitted  to 
each  appropriate  emergency  facility  and  would  be  automatically  provided  to 
the  proper  emergency  control  positions.  Assuming  that  sufficient  controller 
personnel  are  available  at  the  emergency  facilities  and  that  they  are 
adequately  familiarized  with  the  sectors  for  which  they  are  assuming 
responsibility,  a  level  of  service  should  be  obtained  that  is  comparable  to  that 
provided  by  NAS  Stage  A.  Recuperation  from  the  stabilized  state  would  be 
facilitated  since  the  emergency  controllers  would  have  flight  plan  infor¬ 
mation. 

Option  3:  As  in  Option  1,  communication  and  surveillance  sites  would  be 
dual-connected  and  flight  data  and  clearance  plans  would  be  transmitted 
continuously  from  AERA  in  the  ARTCC  to  AERA-type  processing  equipment 
in  the  appropriate  emergency  facilities.  In  this  way,  when  called  upon,  the 
emergency  facilities  would  be  capable  of  providing  full  AERA  capability  in 
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the  region  formerly  under  the  jurisdiction  of  the  failed  ARTCC.  The  number 
of  controllers  needed  to  provide  this  service  from  the  emergency  facilities 
would  be  less  than  the  number  required  in  Option  2,  since  AERA  is  more 
productive  than  NAS  Stage  A.  The  flow  and  density  of  traffic  could  be  larger 
than  in  Option  2  because  AERA  capability  is  maintained  from  emergency 
facilities  despite  the  failure  of  the  ARTCC.  However,  there  is  a  need  to 
transmit  data  continuously  from  each  ARTCC  to  emergency  facilities,  to 
maintain  the  AERA  system  and  software  in  the  emergency  facilities  and  to 
maintain  the  proficiency  of  personnel  in  the  emergency  facilities  to  operate 
AERA  type  control  equipment  for  their  designated  coverages. 

Comparison  of  Options 

Only  detailed  studies  can  determine  the  relative  cost-effectiveness  of 
Options  1,  2  and  3  as  compared  to  the  minimum  recovery  concept. 

The  availability  of  surveillance  information  in  Option  1,  as  compared  to  the 
minimum  recovery  concept,  closes  the  control  loop.  Such  a  system  has  the 
advantage  of  providing  faster  recuperation  and  significantly  increased  reconfigured 
state  capacity  over  that  of  the  minimum  recovery  option. 

Lack  of  flight  plan  and  clearance  information  at  emergency  facilities  in 
Option  1  complicates  the  recuperative  process.  The  lack  of  flight  information 
problem  is,  however,  mitigated  by  the  existence  of  high  quality  surveillance  data 
and  good  communication  facilities.  Given  enough  time,  safe  reconfiguration  can  be 
accomplished  with  these  facilities. 

The  availability  of  flight  plan  information  in  Option  2  facilitates  a  rapid 
recuperation  of  the  system  to  a  NAS  Stage  A  capacity  level,  assuming  trained 
controllers  can  be  made  available.  The  AERA  processing  capability  of  Option  3, 
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permits  rapid  recuperation  to  the  previous  capacity  with  a  minimum  complement 
of  controllers. 

There  is  some  question  as  to  whether  backup  clearances  should  be  issued 
under  Option  3.  If  one  can  have  confidence  that  AERA  is  operative  in  the 
emergency  facilities  and  that  the  few  controllers  needed  to  operate  it  can  be  made 
available  quickly  in  case  of  an  emergency,  then  issuing  backup  clearances  may  be 
more  confusing  than  continuing  to  operate  in  the  AERA  mode.  The  possibility  of 
avoiding  backup  clearances  under  Option  3  has  to  be  studied  more  carefully  as  the 
AERA  program  develops. 

The  relative  capability  of  the  minimum  recovery  concept  and  the  three 
options  is  shown  in  Figure  4-2.  It  can  be  seen  that  traffic  flow  can  be  restored  to 
higher  levels  as  more  elaborate  options  are  implemented,  and  also  the  time  to 
recover  to  a  reconfigured  state  is  likely  to  decrease  as  higher  investment  recovery 
options  are  implemented. 

Figure  4-3  illustrates  the  connectivity  and  equippage  requirements  for  the 
various  options  to  enhance  the  capability  of  the  minimum  recovery  concept. 

4.3.2  Loss  of  AERA  Capability  at  the  ARTCC 

Let  us  assume,  despite  the  efforts  described  in  Section  4.2,  that  AERA 
processing  fails  in  an  ARTCC,  but  that  surveillance  and  communication  capabilities 
survive.  The  minimum  recovery  concept  consists  of  automatic  transmittal  of 
backup  clearances  to  all  aircraft  in  the  affected  control  region,  automatic 
transmission  of  messages  to  adjacent  control  regions  shutting  off  inbound  flow,  and 
automatic  alerting  of  supervisory  and  controller  positions  at  the  affected  facility. 
If  displays  are  still  capable  of  displaying  surveillance  information  at  the  affected 
center,  radar  control  procedures  will  be  used  to  clear  the  impacted  airspace.  If  the 
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displays  have  failed,  along  with  AERA,  despite  the  availability  of  surveillance  data 
at  the  center,  then  open  loop  procedural  control  must  be  used.  For  this  and  other 
reasons,  an  ARTCC's  displays  should  survive  AERA  failures. 

If  surveillance  is  available  at  the  emergency  facilities  and  not  at  the  failed 
ARTCC,  it  is  probably  desirable  for  them  to  assume  control  from  the  affected 
ARTCC.  While  it  is  desirable  to  have  the  emergency  facilities  extend  their 
responsibility  to  the  limits  of  their  surveillance  and  communication  coverage,  it  is 
not  desirable  to  have  them  take  responsibility  for  procedural  control  beyond  their 
coverage,  since  their  controllers  are  not  as  familiar  with  the  airspace  as  the 
controllers  in  the  failed  ARTCC. 

From  this  stabilized  state,  reconfiguration  to  a  NAS-Stage  A  equivalent 
operation  can  begin.  Controllers  in  the  affected  center  will  survey  traffic  flight 
plan  data  and  the  backup  clearances  that  have  been  issued.  Responsibility  shifts 
gradually  to  the  controller  as  he  begins  to  take  control  action,  since  he  is 
responsible  for  those  actions  which  he  initiates.  Boundary  sectors  begin  to  route 
traffic  into  adjacent  control  regions  and  as  able  begin  accepting  traffic  from 
internal  sectors.  Through  a  steady  process,  the  system  moves  toward  taking  all 
aircraft  out  of  backup  clearance  status  and  placing  them  under  active  sector 
control.  Once  this  condition  is  reached,  the  system  is  in  the  reconfigured  state. 
Normal  ATC  system  operation  at  reduced  flow  rates  then  continues  until  AERA  is 
once  again  operative.  The  reduced  flow  rate  is  due  to  two  factors,  aircraft  are 
under  a  NAS-Stage  A  type  control  rather  than  AERA  control  and  the  ARTCC  is 
manned  and  scaled  to  AERA  productivities  rather  than  NAS-Stage  A  capability. 

If  higher  investment  recovery  options  were  implemented,  more  expeditious 
traffic  flows  could  be  maintained.  For  example,  if  AERA  processing  capability  has 
been  installed  at  the  emergency  facilities  and  has  been  maintained  and  con¬ 
tinuously  updated  from  the  center  whose  AERA  has  failed,  the  emergency  facilities 
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can  receive  communications  and  surveillance  data  from  the  failed  center  and  can 
ship  processed  data  to  the  failed  center  to  be  displayed  and  transmitted  as 
appropriate.  Again  this  uses  the  controllers  at  the  damaged  facility  to  manage  the 
airspace.  They  are  most  familiar  with  the  airspace  and  traffic  situation.  In  this 
option  AERA  utilizes  surviving  communication  and  surveillance  resources  with 
augmented  computational  resources  at  emergency  facilities  to  generate  AERA 
outputs  which  are  then  relayed  back  to  the  affected  center.  This  option  assumes 
that  the  Center  design  cans 

•  Ensure  that  AERA  failures  are  independent  of  surveillance  and  com¬ 
munication  failures. 

•  Ensure  that  relayed  AERA  outputs  have  a  survivable  interface  with 
affected  AERA  controller  display  hardware  despite  the  failure  of  the 
local  AERA. 

The  AERA  integrity  concept  does  not  contemplate  the  simultaneous  failure 
of  AERA  processing  and  an  adjoining  communication  or  surveillance  site,  since  as 
discussed  in  Section  4.0,  the  cost  of  protection  against  this  most  unlikely  type  of 
failure  is  likely  to  be  very  high. 

4.3.3  Loss  of  Communications/Surveillance  at  an  AERA  Equipped  ARTCC 

A  loss  of  communication  capability  is  a  disaster,  whether  an  ARTCC  is 
equipped  with  AERA  or  NAS  Stage  A  processing.  It  is  for  this  reason  that  FAA  has 
provided  the  Backup  Emergency  Communications  system  (BUEC)  which  is  designed 
to  maintain  a  communication  service  that  survives  a  wide  range  of  failures.  It  is 
also  for  this  reason  that  FAA  has  implemented  redundant  communication  coverage 
over  most  airspace.  However,  in  the  unlikely  event  that  communication  fails  in  an 
ARTCC  for  a  portion  of  the  airspace,  it  is  necessary  to  assure  that  the  backup 
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clearances  be  automatically  transmitted  to  aircraft  in  that  airspace.  The 
automatic  release  of  backup  clearances  generated  by  AERA,  in  case  of  a 
communication  failure,  does  provide  a  time  buffer  for  establishment  of  an 
emergency  communications  capability.  Such  a  buffer  is  not  available  with  NAS 
Stage  A. 

In  case  of  a  loss  of  surveillance  in  a  portion  of  airspace  controlled  by  AERA 
and  if  multiple  coverage  is  not  available,  it  is  necessary  to  transmit  backup 
clearances  to  aircraft  in  the  affected  airspace  and  to  shut-off  flow  into  that 
airspace.  Procedural  control  has  to  be  used  by  AERA  controllers  to  clear  the 
affected  region.  Until  surveillance  is  restored,  only  the  limited  traffic  under 
procedural  control  can  be  permitted  by  AERA  controllers  in  the  region. 

4.3.4  Loss  of  Some  AERA  Functions 


It  is  more  likely  that  AERA  would  fail  partially  rather  than  totally,  and  it  is 
possible  in  the  case  of  some  of  these  failures  to  maintain  traffic  flow  safely.  For 
example,  if  —  despite  all  precautions  —  the  tactical  executor  and  its  backup  fail 
--  AERA  can  be  designed  to  display  to  an  AERA  controller  the  tactical  decisions 
that  have  to  be  made.  As  long  as  the  traffic  was  sufficiently  light,  so  that  a 
controller  could  make  these  tactical  decisions  and  input  them  to  the  surviving 
AERA,  the  system  could  operate  normally.  As  another  example,  if  the  metering 
function  in  AERA  fails,  but  the  metering  requirement  is  displayed  to  the 
controller,  he  could  input  to  the  strategic  planner  a  metering  strategy  —  "maintain 
aircraft  20  miles  in-trail  along  route  XX"  --  and  AERA  could  operate  with  a 
degree  of  normality. 

A  detailed  schedule  of  failures  within  AERA  that  are  not  catastrophic,  but 
that  can  be  handled  using  manual  inputs,  has  to  be  developed.  Specific  strategies 
and  requirements  have  to  be  designed  to  handle  each  such  partial  failure. 
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4.3.5  Single  Aircraft  Perturbations  to  AERA  Planning 

Whenever  an  inbound  or  departing  aircraft  enters  the  AERA  planning  region, 
a  full  CD  plan  is  generated.  Replanning  is  required  whenever  a  fully-planned  flight 
accumulates  sufficient  longitudinal  deviation  from  its  expected  forward  progress. 
Replanning  is  needed  whenever  AERA  or  a  controller  revises  a  trajectory,  perhaps 
because  of  a  pilot  request  for  a  different  route  or  altitude.  In  any  of  these  cases, 
the  planning  begins  with  a  proposed  new  trajectory  being  submitted  for  (a)  delay 
prediction  and  absorption  planning;  and  for  (b)  conflict  prediction  and  resolution 
planning.  The  result  is  either  (a)  approval  of  the  expected  trajectory  as  submitted; 
or  (b)  proposed  changes  to  this  or  some  other  flight's  CDL. 

If  changes  are  proposed,  each  affected  trajectory  is  edited  appropriately  and 
rechecked  to  ensure  that  it  is  conflict-free  and  metered.  A  key  design  requirement 
is  that  this  process  be  stable  and  convergent  to  an  acceptable  solution  in  a  time 
short  compared  to  the  flying  time  of  the  aircraft  involved  to  the  next  activation 
point. 


4.3.5.1  In-Flight  Failures  and  Emergencies 

Airborne  equipment  sometimes  fails  (e.g.,  voice  radios,  transponders,  navi¬ 
gation  equipment,  data  link  communications,  etc.)  and  occasionally  an  aircraft  runs 
low  on  fuel,  or  suffers  depressurization  at  high  altitude,  or  for  some  other  reason 
declares  an  emergency.  The  AERA  system  is  designed  to  handle  such  problems. 

The  DABS  data  link  can  provide  an  alternative  communication  path  in  case  of 
voice  radio  failure  and  vice  versa.  Prestored  message  formats  with  data  menu 
selection  or  key  pack  entry  for  variable  data  can  be  used  as  a  way  of  quickly 
generating  the  messages.  For  flights  unequipped  with  data  link,  lost  communi¬ 
cation  procedures  would  still  apply.  For  example,  the  pilot  would  follow  his  last 
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clearance  and  other  prescribed  rules  which  permit  him  to  reach  his  destination. 
ATC  will  separate  other  traffic  from  him,  assuming  that  that  will  be  his  strategy. 

Voice  radio  provides  an  alternative  means  for  communicating  altitude  and 
position  reports  to  the  controller  in  case  of  transponder  failure.  The  controller,  at 
his  discretion,  can  use  these  reports  to  manually  update  the  flight's  trajectory. 

Tracked  surveillance  data  can  be  used  to  locate  and  guide  an  aircraft  relative 
to  his  planned  flight  trajectory  in  case  of  navigation  equipment  failure. 

Voice  radio  provides  an  alternative  communications  path  between  the  flight 
crew  or  the  flight's  computer  and  the  controller  or  the  AERA  computer  in  case  of 
DABS  failure.  Pilot/crew  voice  relay  of  down-link  messages  for  controller  data 
entry/action,  and  controller  voice  or  computer  voice  relay  of  up-link  messages  for 
pilot/crew  data  entry/action,  are  the  basic  mechanisms. 

In  case  of  declared  in-flight  emergencies,  the  AERA  system  permits  the 
controller  to  freeze  an  appropriate  flight  trajectory  for  the  aircraft  experiencing 
the  emergency  and  to  force  AERA  to  plan  all  flights  around  it,  thus  giving  priority 
to  the  flight  that  has  declared  an  emergency.  The  trajectory  to  be  frozen  can  be 
different  from  that  planned  prior  to  the  emergency,  or  it  can  have  enlarged 
protection  dimensions  built  around  it,  depending  on  the  nature  of  the  emergency 
and  the  controller's  judgment  on  how  the  flight  should  be  handled.  All  the 
trajectory  modification  and  protection  parameter  tools  necessary  are  provided  by 
the  Man-Machine  Interface  function. 

4.3.5.2  Excessive  Deviations  from  Planned  Profiles 


Reasonable  track  association  with  the  currently  planned  flight  trajectory  is 
one  prerequisite  for  believing  that  any  Clearance  Directives  planned  relative  to 
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that  flight  trajectory  are  valid.  A  track  declared  to  be  now  out  of  association,  or 
predicted  to  go  out  of  association  in  a  short  time,  is  cause  for  an  "out-of¬ 
association  alert".  Any  of  the  following  responses  could  be  programmed: 

1.  Issue  an  out-of-association  alert  to  the  flight  as  a  high  priority  data  link 
message.  Follow  up  with  additional  navigational  assistance  to  regain 
association  or  ask  the  pilot  to  declare  his  intentions  immediately. 

2.  Provide  enlarged  protection  parameters  about  the  trajectory  until  the 
out-of-association  condition  is  cleared.  Replan  any  flight  which  comes 
in  conflict  with  the  enlarged  protected  airspace. 

3.  Post  an  out-of-association  alert  to  the  Man-Machine  Interface.  If 
display  of  the  alert  has  not  been  inhibited,  the  controller  is  informed  of 
the  situation. 

4.3.6  Gross  Perturbations  to  AERA  Planning 

External  events,  such  as  runway  reconfiguration,  airport  closures,  weather 
fronts  or  cells,  navaid  or  neighboring  ATC  facility  outages,  can  suddenly  invalidate 
the  current  clearance  directive  plans  for  a  number  of  flights  simultaneously.  All 
affected  flights  must  be  replanned  in  a  manner  which  meets  relevant  safety  and 
flow  constraints.  Further  replanning  must  be  completed  and  the  plan  executed  (in 
terms  of  issued  and  acknowledged  instructions)  before  each  aircraft  affected 
reaches  its  first  revised  activation  point.  Such  replanning  places  additional 
demands  on  three  kinds  of  ARTCC  resources:  computer,  personnel  and  communi¬ 
cations. 

With  regard  to  computer  resources,  the  analysis  of  a  particular  case  in 
Appendix  7  suggests  that  the  excess  capacity  needed  to  handle  such  peak  demands 


is  not  a  big  increment  over  that  needed  to  handle  the  peak  period  steady  state 
demand.  In  the  case  analyzed,  an  airport  accepting  sixty  aircraft  an  hour  suddenly 
closes.  It  is  assumed  that  the  average  replanning  and  reexecution  time  for  all 
affected  aircraft  is  five  minutes.  Given  the  assumption  that  the  system  is  already 
handling  an  average  load  of  300  flights  in  the  AERA  control  region  plus  150  inbound 
flights  in  the  AERA  planning  region,  the  incremental  increase  in  computer  capacity 
needed  to  redo  the  affected  flights  is  approximately  1 1  percent.  The  implied  limit 
on  the  number  of  computer  operations  that  can  be  executed  per  second,  given 
today's  computer  speeds,  poses  no  real  constraint  on  the  sophistication  of  the 
AERA  planning  and  control  logic  needed  to  meet  such  computational  burdens. 

With  regard  to  personnel  resources,  AERA  is  designed  to  respond  auto¬ 
matically  to  any  gross  perturbation.  If  a  perturbation  occurs,  to  which  AERA 
cannot  respond,  it  automatically  relies  on  prestored  and  preprogrammed  procedures 
that  lower  traffic  flow  rates  and  densities  to  levels  that  can  be  processed  by  the 
available  personnel.  Therefore,  the  need  for  controller  involvement  in  the  initial 
stages  of  the  response  to  a  perturbation  is  minimized.  While  a  controller's  decision 
may  be  required  to  initiate  or  approve  a  replanning  cycle,  the  need  for  a  fast 
response  to  stablize  the  situation  with  safety  legislates  against  significant  con¬ 
troller  involvement  in  the  stabilization  process.  After  the  initial  replanning  is  done 
and  the  time-critical  messages  have  been  transmitted,  then  controllers  may 
become  more  involved  to  reestablish  normal  flows. 

During  the  initial  stabilization  period,  the  demand  for  communication  chan¬ 
nels  to  execute  the  details  of  the  revised  plan  puts  a  lower  limit  on  the  number  of 
voice  frequencies  required,  assuming  computer  voice  is  used  for  aircraft  that  are 
not  DABS  equipped. 
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4.3.6.I  Severe  Weather  Avoidance 

To  avoid  severe  weather,  the  pilot  typically  has  two  choices: 

1.  Request  wider  discretion  laterally  about  his  currently  cleared  route 
centerline,  or  vertically  about  his  current  altitude  assignment,  to  avoid 
storm  cells  or  to  cope  with  turbulence. 

2.  Request  a  specific  new  altitude  assignment  or  amended  route  clearance 
to  overfly  or  bypass  the  disturbance. 

If  the  need  for  rerouting  is  recognized  by  the  ATC  system,  it  typically  has 
two  choices: 

1.  Impose  routing  restrictions  and  clear  affected  flights  via  an  alternate 
route  selected  to  bypass  severe  weather,  assuming  the  pilot  accepts  the 
alternate. 

2.  Advise  each  affected  flight  of  the  weather  situation  ahead  and  ask  the 
pilot  for  his  intentions. 

In  AERA,  pilot-initiated  requests  for  route  amendments  and  different  alti¬ 
tudes  will  be  handled  in  routine  fashion.  If  the  pilot  asks  for  greater  lateral  or 
vertical  discretion  (e.g.,  "Request  fifteen  miles  left  of  route  for  the  next  eighty 
miles  for  weather  cell  avoidance"),  the  protection  parameters  used  by  AERA  for 
protecting  that  flight's  trajectory  can  be  increased  by  the  controller. 

To  support  ATC  planning  of  severe  weather  avoidance  restrictions  and 
rerouting  alternatives,  AERA  provides  a  number  of  aids  to  facilitate  the  man- 
machine  interface.  Severe  weather  can  be  contoured  and  enclosed  with  airspace 
protection  volumes.  Such  boxes  might  be  defined  and  updated  by  the  trained 
meteorologists  at  the  Central  Weather  Service  Unit  (CWSU)  position,  using 
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computer-supported  interactive  graphics  superimposed  on  color  weather  radar 
displays.  Alternate  routes  around  these  weather  enclosures  might  be  defined  by  an 
appropriate  ATC  position  on-line  to  AERA. 

Restrictions  and  alternate  routings  can  be  read  up  automatically  to  all 
affected  flights  via  data  link  or  voice,  along  with  a  brief  explanation  of  the  cause. 
Pilots  understanding  the  restriction,  but  desiring  another  alternative,  could  down¬ 
link  their  requests  for  AERA  processing  as  in  the  case  of  any  other  flight  plan 
amendment.  Those  desiring  controller  assistance  may  obtain  it  via  voice  radio  or 
data  link. 


4.3.6.2  Airport  Closures  and  Other  Flow  Restrictions 

Any  number  of  external  events  can  slow  or  block  the  flow  of  traffic  along  one 
or  more  routes:  temporary  airport  closures,  sudden  changes  in  airport  acceptance 
rates,  other  bottlenecks.  The  net  effect  is  that  forward  progress  to  the  destination 
of  one  or  more  flights  is,  or  will  be,  temporarily  blocked  beyond  a  certain  point  on 
each  flight's  trajectory.  When  such  a  condition  is  imposed,  a  clearance  limit 
restriction  is  imposed  on  each  flight  along  with  an  estimated  Expect  Further 
Clearance  time.  If  the  Expect  Further  Clearance  time  exceeds  the  pilot's  desire  to 
wait,  then  he  may  elect  to  be  recleared  to  an  alternate  destination.  If  not,  then 
forward  progress  will  be  delayed  until  the  restriction  is  satisfied.  If  the  affected 
flights  are  not  to  be  rerouted,  it  is  necessary  that  AERA  handle  the  bulk  of  the 
workload  associated  with  absorbing  the  necessary  delays  in  a  safe  and  efficient 
manner.  This  process  is  handled  by  the  delay  prediction  and  absorption  tools 
previously  described. 

Strategically,  AERA  would  identify  the  flights  inbound  to  the  clearance  limit. 
It  would  form  a  queue  of  those  flights  with  an  Expected  Further  Clearance  time 
appended  to  each.  The  difference  between  the  Expected  Further  Clearance  time 
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and  the  current  Calculated  Time  of  Arrival*  at  the  clearance  limit  is  the  currently 
estimated  delay.  Discounting  for  prediction  errors  may  be  suspended  since  delay 
absorption  tools  beyond  the  clearance  limit  cannot  now  be  counted  upon. 

The  delay  is  allocated,  if  possible,  to  along-course  speed  reductions  or  to 
path-stretching  vectors,  if  lead-time  permits.  If  not,  holding  at  the  next  available 
holding  fix  is  required.  This  fix  may  be  along  the  cleared  route  (including  a 
"present  position  hold"),  or  off  the  cleared  route,  given  controller  approval  for 
reclearance  to  the  latter. 

The  availability  of  holding  airspace,  as  compared  to  demand,  will  be 
monitored  by  AERA  and  posted  for  supervisory  and  controller  utilization.  Should 
holding  airspace  availability  become  a  problem,  the  cognizant  supervisor  would 
coordinate  the  necessary  restrictions  to  limit  flow  bound  for  the  affected  airspace. 

Tactically,  AERA  would  clear  each  aircraft  into  a  holding  pattern  with 
Expected  Further  Clearance  time  advisories,  issue  the  necessary  speed  reduction, 
or  issue  the  necessary  path-stretching  vectors  (dog-legs  or  S-turns  relative  to  the 
cleared  route).  If  present  position  holds  are  needed  by  the  aircraft  nearest  the 
clearance  limit,  this  would  be  dealt  with  first.  Those  aircraft  being  held  would  be 
cleared  out  of  the  hold  as  the  terms  of  the  restriction  are  satisfied.  AERA  would 
manage  any  altitude  transitions  necessary  while  aircraft  are  being  held. 


*The  Calculated  Time  of  Arrival  is  the  computer's  estimate  of  a  flight's  arrival 
time.  It  may  not  coincide  with  the  pilot's  Estimated  Time  of  Arrival  (ETA), 
although  the  two  times  should  generally  agree. 
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5.0  AERA  and  Airspace 

The  airspace  structure  is  defined  by  a  variety  of  air  routes,  bounded  volumes 
of  airspace  and  procedural  agreements  among  ARTCCs,  TRACONs  and  towers. 
Some  of  the  elements  of  the  airspace,  such  as  3et  Routes,  Standard  Arrival  Routes 
(STARs),  and  Standard  Instrument  Departures  (SIDs),  are  applicable  only  to  IFR 
aircraft,  while  other  elements,  including  Victor  Airways,  sectors,  control  zones, 
prohibited  and  restricted  areas,  TCAs,  TRSAs,  involve  aircraft  operating  under 
VFR  as  well.  The  airspace  structure  and  traffic  handling  procedures  has  evolved  in 
a  way  that  permits  as  expeditious  a  flow  of  traffic  as  is  consistent  with  the 
controllers'  and  pilots'  ability  to  handle  aircraft  safely,  given  the  various  tools 
available  to  them.  For  controlled  airspace,  these  tools  include  knowledge  of  intent 
obtained  through  flight  plan  processing  and  through  the  routing  of  traffic  on  fixed 
airways,  confirmation  of  intent  by  tracking  data,  and  a  situation  display.  These 
available  tools  have  constrained  the  horizontal  and  vertical  separation  of  traffic  to 
be  accomplished  primarily  by  in-trail  spacing  or  merge  sequencing  with  a  minimum 
of  crossing  traffic  within  a  sector.  Furthermore,  most  of  the  transition  airspace 
above  an  aircraft  that  is  climbing  or  below  one  that  is  descending  must  be  clear. 

Limitations  on  the  number  of  aircraft  that  can  be  separated  in  this  manner  by 
a  single  human  controller  have  caused  the  airspace  to  be  divided  into  many  sectors, 
each  the  responsibility  of  a  control  team,  and  to  constrain  flight  principally  to 
airways  traversing  many  sectors.  The  historical  ATC  process  requires  handoffs 
from  controller  to  controller  and  subsequent  VHF  voice  radio  frequency  changes. 
At  times  transponder  code  changes  are  also  required  as  the  aircraft  proceed  from 
sector  to  sector. 

A  computer,  given  aircraft  flight  plans  and  surveillance  data,  can  readily 
track  aircraft  and  search  for  potential  conflicts  in  four  dimensions,  despite 
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numerous  instances  of  crossing  flight  paths  and  complex  conflict  resolution 
geometries.  These  are  the  kinds  of  trajectories  that  would  result  from  the  use  of 
many  direct  routings,  profile  descents  and  fuel-efficient  climb-outs.  A  controller 
cannot  predict  potential  conflicts  with  this  unstructured  traffic  as  expeditiously  as 
a  computer.  The  extensive  data  base  and  high-speed  processing  ability  of  AERA 
afford  the  opportunity  for  changing  the  control  practices  used  to  ensure  com¬ 
pliance  with  separation  standards,  and  possibly  for  some  changes  in  the  standards 
themselves. 

As  an  example,  consider  the  procedural  cruise  altitude  restriction  illustration 
in  Figure  5-1.  Until  recently,  short  haul  flights  from  LaGuardia  (LGA)  to 
Washington  National  Airport  (DCA)  were  routinely  restricted  to  a  cruise  altitude  of 
16,000  feet.  This  restriction  was  recently  raised  to  20,000  feet  southbound.  The 
reasons  for  this  restriction,  as  reported  in  Reference  1,  included  the  possibility  of  a 
crossing  conflict  with  one  or  more  JFK  departures  climbing  out  on  westbound 
routes  and  crossing  the  LGA...DCA  route  at  altitudes  above  20,000  feet.  Also,  it 
was  desired  to  keep  the  southbound  traffic  out  of  the  overlying  high  altitude 
sectors  to  limit  controller  workload.  The  fuel  penalty  to  the  short  haul  aircraft 
was,  however,  significant:  seven  to  eight  percent  for  a  B727  in  standard 
atmospheric  conditions.  With  the  restriction  now  at  20,000  feet,  that  penalty  has 
been  cut  at  least  in  half.  Similar  restrictions  are  encountered  by  most  short  haul 
turbojets  flying  between  Washington,  D.C.  and  New  York  airports. 

One  possible  solution  to  such  procedural  altitude  restrictions  is  illustrated  in 
Figure  5-2.  The  figure  shows  how  the  "conflict  box"  (see  Appendix  4)  concept  in 
AERA  might  be  used  to  eliminate  the  need  for  any  fixed  cruise  altitude  restriction. 
The  illustration  shows  two  departures  out  of  JFK,  one  climbing  to  high  altitude  via 
Robbinsville  and  J64,  and  the  other  climbing  to  high  altitude  via  the  Freehold  7 
standard  instrument  departure  to  Robbinsville  to  join  J80.  Potentially  conflicting 
with  them  is  a  departure  out  of  LGA  bound  for  DCA. 
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Privileged  Aircraft:  JFK  Hedlun  &  Long  Haul* 

Burdened  Aircraft:  LGA  Short  Hauls 

Initial  Clearance:  "Cl lab  &  nalntaln  160,  Expect  higher 
before  reaching  160 
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In  the  Context  of  the  Hew  York  Short  Haul  Problea 
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In  this  particular  case,  the  computer  has  found  that  the  highest  available 
southbound  altitude  for  the  short  haul  flight  is,  in  fact,  20,000  feet  MSL.  However, 
actual  traffic  statistics  for  these  routes  have  shown  that  such  encounters  are 
relatively  rare,  approximately  one  percent  of  the  time  on  the  average  and  three 
percent  during  periods  of  peak  traffic.  This  implies  that  in  most  cases,  the  altitude 
profile  desired  by  the  short  haul  flight  would  be  found  to  be  without  conflicts  and 
that  the  altitude  restriction  would  not  be  necessary. 

In  summary,  AERA  would  automatically  predict  whether  the  flight's 
requested  profile  is  conflict-free  or  not,  establish  the  assigned  altitude  as  either 
the  flight's  requested  altitude  or  the  highest  available  altitude  for  a  given  conflict 
situation.  This  information  would  be  utilized  by  AERA  to  generate  clearances  in 
the  manner  described  in  Section  3. 

This  example  illustrates  the  kind  of  procedural  restrictions  that  are  often 
imposed  on  controlled  flights  operating  in  the  airspaces  surrounding  the  busier  hub 
areas.  Several  efforts  are  underway  in  the  context  of  the  NAS  Stage  A  system  to 
see  if  such  restrictions  can  be  relaxed  in  the  interest  of  fuel  efficiency,  but  such 
efforts  cannot  sacrifice  the  requirements  to  maintain  system  safety  under  all 
traffic  loads  and  to  maintain  controller  productivity  levels.  Given  these  require¬ 
ments  and  the  constraints  of  current  ATC  system  capabilities,  it  is  proving 
difficult  to  remove  or  relax  many  of  these  restrictions. 

However,  highly  automated  ATC  systems  may  themselves  cause  some  types 
of  restraints  on  airspace  utilization.  To  some  degree,  the  system  failure  and 
recovery  modes  that  must  be  integrated  with  any  automated  system  design  restrict 
the  extent  to  which  more  conservative  guidelines  can  be  relaxed.  If  any  such 
failure  occurs,  the  system  design  should  allow  rapid  and  effective  system  stabili¬ 
zation  in  a  way  that  does  not  place  the  controller  in  an  untenable  situation.  See 
Section  4.3.1.  This  requirement  does  impact  airspace  design  and  loading.  In  every 
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case,  AER A's  clearances  will  attempt  to  guarantee  at  least  ten  minutes  of  conflict-free 
f  light, hencesystem  stabilization  has  available,  in  general,  that  much  time  before  backup 
systems  need  to  be  operational. 

Using  AERA,  airspace  procedures  and  structures  are  likely  to  vary  signifi¬ 
cantly  with  time.  Oust  as  sectors  are  currently  combined  for  handling  by  one 
control  team  during  night  time  operations  or  other  periods  of  low  traffic  density, 
sector  boundaries  within  AERA  planning  regions  can  assume  any  one  of  several 
configurations  to  match  the  volume  of  traffic  flow.  Separation  parameters  and 
control  practices  would  also  be  flexible,  becoming  functions  of  such  parameters  as 
wake  vortex  generating  capacity  of  an  aircraft,  surveillance  accuracy  and  update 
rate,  avionics  (including  data  link),  and  system  load.  The  ability  of  an  automated 
data  processing  system  in  which  many  parameters  are  resident  to  compile  and 
maintain  files  of  information  on  each  aircraft  in  the  system,  enables  AERA  to  use 
such  information  to  prevent  unnecessarily  conservative  separation  procedures  from 
being  applied.  This  extensive  use  of  available  data  will  allow  AERA  to  increase  the 
productivity  and  capacity  of  air  traffic  control,  while  maintaining  or  increasing  the 
current  level  of  safety. 

AERA's  impact  on  airspace  structure  may  lead  to  a  reduction  in  the  number 
of  required  radio  frequency  changes  as  aircraft  proceed  along  their  flight  paths. 
Furthermore,  while  the  controller  will  become  responsible  for  communication  with 
a  larger  number  of  aircraft  than  he  currently  handles,  increased  data  communi¬ 
cations  should  reduce  the  voice  traffic  over  a  single  link  during  routine  operations. 
During  emergencies  the  recovery  options  proposed  in  5ection  4  provide  sufficient 
time  for  controllers  to  contact  aircraft  needing  service. 

AERA  can  be  applied  in  most  airspace.  In  positively  controlled  airspace  the 
flight  plans  and  surveillance  data  available  to  AERA  allow  it  to  provide  conflict- 
free  clearances  with  greater  freedom  of  choice  for  the  aircraft  involved  and  with  a 
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higher  level  of  safety.  In  mixed  airspace,  AERA  also  may  provide  automatic 
traffic  advisories  because  of  its  ability  to  predict  conflicts  involving  VFR  aircraft 
for  which  surveillance  data  are  sufficient  to  establish  reliable  tracks.  Such  data 
may  span  the  spectrum  from  only  primary  radar,  if  available,  to  the  highest  quality 
DABS  information.  Although  AERA's  tasks  are  simplified  and  the  quality  of  its 
service  improved  in  that  high-density  airspace  where  DABS  transponders  with 
altitude  encoders,  may  ultimately  be  required,  AERA's  success  is  not  dependent  on 
universal  implementation  of  DABS. 

VFR  aircraft  are  able  to  take  advantage  of  some  of  the  features  of  AERA  by 
requesting  traffic  advisories  just  as  they  do  today.  Even  aircraft  without 
transponders  may  be  able  to  receive  advisory  services  when  the  quality  of  primary 
radar  data  available  to  AERA  affords  reliable  tracking.  Such  services  could  be 
conveyed  by  computer-generated  voice  over  VHF  voice  radio,  once  the  track  was 
initiated  and  the  aircraft  identity  established.  A  much  higher  quality  service  would 
be  provided,  of  course,  to  transponder-equipped  aircraft.  The  provision  of  a  VFR 
flight  plan  would  help  AERA  perform  its  functions  in  a  mixed  airspace,  but  would 
not  be  mandatory. 

The  flexible  nature  of  AERA  allows  its  features  to  be  used  up  to  some 
terminal  boundary,  approach  fix  or  landing  system  marker  to  allow  for  subsequent 
fine  spacing  of  terminal  traffic.  This  terminal  boundary  or  transition  region  also 
varies  with  time  and  traffic  density  to  allow  safe  and  expeditious  flow  of  traffic  to 
and  from  the  ground.  Thus,  AERA  is  applicable  to  some  transition  airspace 
controlled  by  TRACONs,  as  well  as  to  en  route  airspace. 

The  simultaneous  use  of  both  conventional  air  routes  and  direct  RNAV  flight 
paths  in  the  same  airspace  is  facilitated  by  AERA. 
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Airborne  data  gathering  and  transmission  (weather,  in-flight  performance 
measurement  and  other  data)  are  essential  to  the  compilation  of  a  complete  data 
base  that  allows  AERA  to  predict  each  participating  aircraft's  trajectory  and,  if 
necessary,  provide  conflict-avoidance  maneuvers  in  the  most  effective  manner 
possible.  Although  a  DABS  transponder  with  altitude  encoder  and  data  link  provide 
a  fast,  reliable  communication  link  that  would  make  AERA  more  productive  in 
high-density  airspace,  adopting  a  transponder  1DENT  procedure  or  providing  a  pilot 
with  a  simple  touchpad  used  in  conjunction  with  a  standard  VHF  transmitter  aboard 
smaller  aircraft,  allows  AERA's  productivity  improvements  to  be  rendered  to  a 
very  broad  segment  of  the  aviation  community.  A  full  discussion  of  this  is 
contained  in  Section  8. 

Although  AERA  is  basically  a  surveillance-oriented  system,  it  is  conceivable 
that  procedural  versions  of  the  system  coyid  be  developed  and  implemented  for 
some  airspace  where  non-radar  procedures  are  currently  employed.  Oceanic 
regions  and  terminal  island  facilities  like  Honolulu  and  San  3uan,  for  example,  may 
be  able  to  provide  AERA  services  beyond  radar  coverage  as  long  as  safe  separation 
procedures  can  be  based  on  aircraft  navigation  and  radio  contact  can  be  main¬ 
tained.  Within  radar  coverage,  or  course,  oceanic  and  terminal  island  facilities  can 
provide  services  in  the  same  manner  as  continental  centers. 
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6.0  The  Controller  and  AERA 


Controllers  have  had  the  responsibility  for  separation  assurance  and  metering 
of  traffic,  whether  procedural  techniques,  radar  control  using  shrimp  boats  or  NAS 
Stage  A  were  employed.  This  responsibility  can  be  delegated  to  pilots  with  their 
concurrence  under  appropriate  conditions.  In  AERA,  the  controller  has  the 
responsibility  for  the  system  that  provides  separation  and  metering,  but  unless  he  is 
alerted  by  a  pilot  or  AERA  to  an  unusual  situation,  he  is  not  responsible  for  routine 
separation  and  metering.  AERA  is  designed  to  warn  the  controller  of  unusual 
situations  and  at  that  point  the  controller  becomes  responsible.  Also,  AERA  is 
designed  so  that  a  pilot  can  request  that  the  controller  take  command  at  any  time. 
However,  AERA  is  also  designed  so  that  a  controller  is  never  placed  in  an 
untenable  situation.  A  conflict  alert,  generated  by  AERA's  backup  system,  is 
provided  in  sufficient  time  for  a  controller  to  review  and  evaluate  a  potentially 
dangerous  situation.  The  solutions  proposed  by  AERA  are  transmitted  to  aircraft, 
unless  the  controller  intervenes.  In  case  of  a  massive  AERA  failure,  backup 
clearances,  as  described  in  Section  4.3.1,  stabilize  the  traffic  until  manual  or 
automatic  control  can  be  instituted  from  adjoining  backup  facilities. 

The  controller  is  in  the  loop  in  today's  system.  The  controller  is  not  in  the 
loop  in  AERA  with  respect  to  aircraft  control,  neither  is  he  required  to  monitor 
clearances.  AERA  or  a  pilot  might  ask  the  controller  to  monitor  or  handle  certain 
situations,  but  this  is  control  by  exception.  The  controller  is  the  manager  of  AERA 
and  traffic  flow,  but  normally  does  not  control  individual  aircraft.  He  is  provided 
with  system  status,  weather,  traffic  demand  and  capacity  displays  to  perform  his 
managerial  responsibilities,  as  described  below. 

In  this  manner,  the  controller  is  relieved  of  routine,  which  should  minimize 
errors,  and  has  the  more  rewarding  responsibility  of  creatively  using  ATC  and 
AERA  assets  to  satisfy  traffic  demand. 


Ill 


6.1  General  Controller  Responsibilities 

In  today's  ATC  system,  the  responsibility  for  the  provision  of  separation  and 
other  ATC  services  is  unambiguously  assigned  by  the  establishment  of  sectors. 
AERA  does  not  eliminate  the  need  for  the  unambiguous  definition  of  responsibility. 
It  requires  that  responsibility  not  only  be  clearly  defined  between  individuals,  but 
between  individuals  and  machine  as  well. 

In  an  AERA  environment,  responsibility  would  continue  to  be  assigned  by 
precisely  defined  boundaries.  AERA  sectors,  significantly  larger  than  today's 
sectors,  are  defined  to  assign  controllers  to  specific  airspace  areas.  AERA 
airspace  areas  are  differentiated  from  airspace  areas  where  conventional  ATC 
techniques  are  employed.  Within  AERA  airspace  areas,  AERA  assumes  the 
responsibility  for  the  separation  and  metering  of  aircraft  with  the  controller 
managing  the  assets  of  the  AERA  system  and  assuming  control  only  by  exception. 
Outside  AERA  airspace  areas,  the  controller  continues  to  assume  full  responsibility 
for  the  separation  and  metering  of  aircraft.  During  transition  there  may  be 
airspace  operated  conventionally  but  with  AERA  tools  available. 

A  major  concern  with  control-by-exception  concepts  is:  "Can  an  individual 
serve  as  an  effective  monitor  or  controller  of  a  process  in  which  he  or  she  is  not 
intimately  involved?"  This  should  not  be  a  major  problem  in  that  the  controller 
will  continue  to  be  involved  in  ATC  processes  even  with  the  advent  of  AERA.  The 
controller  may  be  called  on  to  resolve  isolated  potential  conflicts,  but  he  does  not 
resolve  every  potential  conflict.  He  is  called  on  to  review  traffic  flows,  but  not  to 
meter  aircraft.  Furthermore,  AERA  is  designed  to  fail  in  such  a  way  that  the 
controller  cannot  be  overloaded,  as  discussed  in  Section  4.3. 

At  an  AERA  boundary,  the  neighboring  controller  managing  aircraft  conven¬ 
tionally,  is  given  the  tools  for  interacting  with  AERA  so  that  aircraft  can  be 
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handed  into  and  out  of  the  AERA  system.  For  aircraft  entering  AERA  assigned 
airspace,  the  conventional  controller  is  required  to  ensure  that  an  AERA  clearance 
is  issued  and  acknowledged  by  the  pilot  before  boundary  crossing  is  allowed.  For 
aircraft  exiting  AERA  airspace,  the  neighboring  conventional  controller  is  required 
to  verify  that  the  existing  AERA  clearance  provides  separation  from  all  known 
aircraft  prior  to  allowing  boundary  crossing  outbound.  At  the  boundary  the 
controller's  role  within  the  AERA  assigned  airspace  is  to  respond  to  am  AERA  alert 
indicating  that  an  aircraft  is  either  entering  or  leaving  AERA  controlled  airspace 
without  the  needed  coordination  and  approvals. 

6.2  Controller  Requirements  Within  AERA  Assigned  Airspace 

Within  AERA  assigned  airspace,  the  controller  is  required  to  provide  a 
variety  of  services.  These  services  are  discussed  below  under  the  categories  of 
communications,  finding  efficient  solutions,  non-routine  operations,  unresolved 
conflicts,  weather,  holding  and  supervisory  functions.  While  these  categories  are 
probably  not  exhaustive  of  controller  functions  using  AERA,  they  represent  a 
substantial  portion  of  his  responsibility. 

6.2.1  Communications 


In  AERA  assigned  airspace,  routine  communication  tasks  are  handled  auto¬ 
matically.  Aircraft  which  are  DABS  equipped  communicate  with  ATC  via  data 
link.  For  non-data  link  equipped  aircraft,  routine  transmission  of  clearances  and 
information  is  accomplished  by  computer  generated  voice.  Acknowledgement  of 
clearances  could  be  accomplished  by  a  low-cost  touch-tone  panel  adapted  to  the 
VHF/UHF  link,  or  possibly  by  utilizat'on  of  the  transponder  identification  feature. 
A  range  of  communication  tasks  are,  however,  left  for  the  controller. 
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For  non-data  link  equipped  aircraft,  the  controller  is  required  to  handle  all 
information  received  from  the  air  that  cannot  be  handled  routinely  by  the  methods 
described  above.  For  data  link  equipped  aircraft,  the  controller  is  required  to 
handle  communications  not  easily,  or  readily,  formatted  for  data  link.  The 
negotiation  process  that  takes  place  between  the  ATC  system  and  a  pilot  when  a 
clearance  does  not  meet  a  pilot's  desires  or  requirements  is  one  example  of  this 
type  of  communication.  The  controller  also  becomes  involved  when  clarification  of 
a  clearance  is  required  and  when  emergency  or  unusual  situations  are  encountered. 

6.2.2  Finding  Efficient  Solutions 

AERA  software  may  include  a  routine  which  looks  at  the  restrictiveness  of 
planned  clearances  or  the  complexity  of  the  plan  controlling  an  individual  flight. 
If,  when  compared  to  the  diagnostic  criteria,  clearances  are  found  to  be  exces¬ 
sively  restrictive  or  complex,  the  ccTttroller  would  be  alerted  by  the  computer  to 
the  excessive  complexity  of  the  proposed  clearance.  The  controller  would 
intervene  if  a  more  appropriate  solution  than  the  one  enbedded  in  the  AERA 
algorithms  can  be  developed  manually. 

6.2.3  Non-Routine  Operations 

There  exist  in  today's  ATC  environment  a  variety  of  flight  operations  which 
occur  frequently  but  require  services  other  than  separation  from  other  aircraft  and 
metering  to  the  destination.  It  is  not  envisioned  that  AERA  software  can  be 
developed  to  handle  each  and  every  type  of  operation  that  can  be  expected. 
Controller  involvement  can  be  anticipated  in  such  operations  as  aerial  refueling, 
formation  flight  join  up  and  breakup,  fuel  dumping,  and  parachute  jumping. 

There  also  exists  a  large  number  of  types  of  unusual  operations  which  require 
priority  handling.  In  some  cases  the  call  sign  in  use  will  identify  the  need  or  type 
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of  priority  required;  in  other  cases  the  controller  is  required  to  provide  this 
information  to  the  computer  (system).  In  any  case,  it  is  envisioned  that  for  these 
types  of  operations  the  controller  is  required  to  remain  cognizant  of,  and  in  some 
cases,  assume  responsibility  to  ensure  that  the  service  provided  is  consistent  with 
the  needs  of  the  flight.  Examples  of  the  types  of  operations  which  require  priority 
handling  are  emergencies,  lifeguard  flights,  SAFI  flights,  Navy  "Special  Call  Sign" 
operations,  and  so  on. 

6.2.4  Unresolved  Conflicts 

While  AERA  software  must  be  thoroughly  tested,  the  possibility  exists  that 
the  AERA  algorithms  will  fail  to  resolve  an  aircraft  conflict.  As  a  backup  to 
normal  AERA  conflict  resolution,  an  independent  separation  assurance  monitoring 
function  is  planned.  In  the  event  that  this  conflict  alert  is  triggered,  this  backup 
AERA  function  alerts  the  controller  to  its  planned  resolution  and  is  prepared 
automatically  to  issue  avoidance  instructions,  if  the  controller  does  not  intervene. 
The  conflict  alert  function  would  not  normally  be  triggered,  and  the  controller 
should  be  made  aware  only  of  abnormal  events.  However,  the  controller  is  not 
made  responsible  for  a  time-critical  decision,  as  AERA  will  be  prepared  to  resolve 
the  conflict.  The  controller  may  also  be  required  to  issue  instructions  to 
reestablish  the  aircraft  involved  on  its  flight  plan,  although  it  is  conceivable  that 
AERA  software  could  accomplish  this. 

6.2.5  Weather 

AERA  would  continue  to  utilize  the  same  approach  to  severe  weather 
avoidance  as  today's  system.  Specifically,  those  aircraft  with  the  ability  to  detect 
areas  of  severe  weather  will  be  allowed  the  freedom  to  navigate  so  as  to  avoid 
these  areas  as  long  as  the  limits  to  pilot  discretion  are  defined.  Aircraft  without 
the  ability  to  detect  severe  weather  will  be  advised  of  the  weather  information 
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available  and  will  be  provided  avoidance  assistance  if  it  is  requested.  (Flow  control 
actions  as  methods  of  coping  with  large  areas  of  severe  weather  are  discussed  in 
Section  6.2.7) 

The  pilot  of  an  equipped  aircraft  requests  authority  to  deviate  within  given 
bounds  for  the  purpose  of  weather  avoidance.  The  AERA  system  expands  the 
protection  volume  for  the  aircraft  consistent  with  the  request  if  there  are  no 
potential  conflicts  and  then  approves  the  requested  deviation,  as  described  in 
Section  4.3 .6.1.  It  is  possible  that  the  request  and  approval  can  occur  without 
controller  involvement  assuming  appropriate  aircraft  equippage.  If,  however,  the 
request  for  deviation  results  in  a  conflict  and  AERA's  proposed  resolution  of  the 
conflict  is  unacceptable  to  the  pilot,  then  a  negotiation  process  has  to  be 
undertaken  to  arrive  at  an  acceptable  solution.  This  negotiation  process  may  result 
in  an  alternate  avoidance  action  on  the  part  of  the  affected  aircraft  or  in  a 
restriction  on  the  traffic  interfering  with  the  proposed  conflict  resolution.  In  any 
event,  this  negotiation  process  might  require  the  controller  to  devise  alternatives 
acceptable  to  the  aircrew. 

Some  aircraft  may  become  equipped  with  cockpit  displays  on  which  appro¬ 
priate  weather  data  could  be  shown.  It  is  planned  to  transmit  weather  data 
appropriately  filtered  to  aircraft  by  means  of  the  DABS  data  link.  Aircraft  not 
equipped  with  DABS  or  displays  have  to  receive  this  data  verbally  from  the 
controller.  Controller  involvement  with  those  aircraft  that  are  not  equipped  with 
weather  sensing  equipment  or  DABS  and  cockpit  displays,  is  likely  to  be  sub¬ 
stantial.  If  significant  weather  came  in  single,  well  defined,  easily  described  areas, 
this  would  not  be  the  case.  Areas  of  significant  weather,  however,  often  are 
scattered  over  wide  areas  in  difficult  to  describe  patterns.  Providing  the  pilot  with 
sufficient  information  upon  which  he  or  she  may  base  a  request  for  assistance  often 
requires  a  detailed  description  of  what  is  being  observed  and  transmission  of 
information  as  to  what  other  aircraft  have  experienced. 
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6.2.6  Holding 

Implementation  of  DABS  and  a  high  level  of  DABS  transponder  equippage 
would  permit  surveillance  to  be  maintained  for  aircraft  in  holding  stacks.  With  this 
surveillance,  the  successful  development  of  efficient  holding  pattern  management 
algorithms  is  likely.  Without  DABS,  and  the  resultant  ungarbled  surveillance  of 
holding  patterns,  however,  AERA  management  of  holding  patterns  requires  con¬ 
tinuous  input  of  altitude  updates  by  either  the  controller  or  pilot.  Additionally, 
non-surveillance  based  management  would  likely  result  in  inefficient  flow  from 
holding-patterns.  Given  these  problems,  without  ungarbled  surveillance,  a  large 
part  of  the  burden  of  managing  holding  patterns  fails  on  the  controller. 

6.2.7  AERA  Supervisory  Functions 

An  AERA  supervisory  position  from  which  functions  equivalent  to  those 
currently  performed  by  the  flow  controller  is  incorporated  in  AERA.  The 
individuals  staffing  this  position  will  use  information  on  airport  acceptance  rates, 
system  perturbations,  and  weather  information  in  conjunction  with  sector  workload 
and  traffic  complexity  diagnostics  to  determine  the  need  for  such  actions  as  flow 
control,  resectorization  and  traffic  flow  rerouting. 

6.3  Controller  Interaction 


As  discussed  in  the  preceding  section,  it  is  anticipated  that  although  AERA 
significantly  reduces  controller  workload  by  taking  over  routine  functions,  con¬ 
troller  involvement  in  ATC  processes  continues  to  be  required.  In  the  following 
two  subsections  there  is  a  brief  discussion  of  the  levels  of  controller  interaction 
and  the  displays  which  allows  this  interaction. 


6.3.1  Levels  of  Interaction 


Two  fundamental  levels  of  controller  interaction  with  AERA  processes  are 
anticipated.  These  are  open  loop  interaction  and  closed  loop  interaction. 

Although  certainly  an  exception,  it  is  anticipated  that  a  controller  may  wish 
to  take  over  control  of  an  aircraft  and  for  the  sake  of  expediency  may  not  for  a 
time  wish  to  input  all  clearance  items  to  the  computer.  In  this  event  it  is 
envisioned  that  a  computer  entry  by  call  sign  will  disable  routine  AERA  conflict 
resolution  for  the  identified  aircraft.  The  controller  then  assumes  full  respon¬ 
sibility  for  separating  this  aircraft  from  all  other  traffic.  It  is  anticipated  that  the 
controller  can  call  up  AERA  conflict  predictions  based  on  known  information  for 
the  aircraft  and  that  conflict  alert  processing  is  not  disabled.  Metering  processing 
would  also  continue  and  would  provide  the  controller  with  information  as  to 
necessary  delay  and  possible  actions  to  absorb  this  delay. 

The  category  of  closed  loop  interaction  involves  the  full  range  of  activities  in 
which  the  controller  imposes,  for  whatever  reason,  his  wishes  on  the  system,  but 
allows  the  system  to  retain  control  of  the  aircraft  involved.  This  category 
represents  the  normal  manner  in  which  the  controller  works  with  AERA.  Examples 
of  this  type  of  interaction  are  as  follows: 

1.  The  computer  proposes  an  altitude  restriction  for  the  resolution  of  a 
conflict,  that  the  controller  for  special  reasons  is  monitoring,  but  the 
controller  believes  the  assignment  of  a  heading  would  be  more  appro¬ 
priate.  The-  controller  instructs  the  system  to  use  heading  assignment 
for  resolution  and  advises  the  system  which  aircraft  is  to  be  turned. 
The  calculation  of  the  appropriate  vector  and  the  issuance  of  the 
clearance  is  left  to  the  computer.  The  computer  advises  the  controller 
if  it  finds  any  faults  with  the  controller's  plan.  The  controller  may 
recognize  that  the  computer  found  a  problem  overlooked  by  him,  or  he 
may  choose  to  ignore  the  computer's  reply  and  impose  his  own  plan  via 
an  override. 


118 


2.  The  controller  is  informed  that  a  particular  aircraft  must  cross  a  fix  at 
an  altitude  for  a  purpose  not  known  to  the  system.  The  controller 
inputs  the  restriction  to  the  computer.  The  computer  formulates  an 
efficient  clearance  plan  based  on  this  restriction. 

3.  The  controller  designates  a  flight  as  requiring  priority  handling.  The 
computer  bases  all  resolutions  on  providing  this  aircraft  priority. 

It  is  envisioned  that  AERA  displays  provide  planning  tools  to  allow  the 
controller  to  fully  assess  the  impact  of  his  actions.  A  control  instruction  imposed 
by  the  controller  in  closed  loop  mode  is  therefore  taken  as  a  system  constraint.  If 
this  control  instruction  creates  conflicts  with  other  aircraft  and  resolutions  for 
these  conflicts  are  not  specified,  AERA  takes  appropriate  action  to  resolve  these 
conflicts  within  the  latitude  allowed  by  the  specified  instruction. 

6.3.2  AERA  Displays 

AERA  displays  are  an  outgrowth  of  those  in  use  in  today's  en  route 
environment. 

Current  sector  data  displays  consist  of  a  plan  view  display,  two  computer 
readout  devices,  and  flight  progress  strips.  While  information  can  be  called  up  on 
the  computer  readout  devices,  these  devices  serve  primarily  as  preview  areas  with 
most  actively  used  data  displayed  either  on  the  plan  view  display  or  on  the  flight 
progress  strips. 

The  plan  view  display  displays  aircraft  radar  targets  with  histories  to  provide 
an  indication  of  velocity  and  turn  rate.  Associated  with  each  target  is  a  data  block 
providing  information  as  to  call  sign,  assigned  altitude,  actual  altitude  and  ground 
speed.  This  display  provides  the  information  necessary  for  the  controller  to  quickly 
assess  the  immediate  traffic  picture. 
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The  supplemental  information  necessary  to  allow  more  long  term  projection 
and  fuller  understanding  of  the  traffic  flow  is  provided  by  the  flight  progress  strips. 
The  flight  progress  strip  provides  information  as  to  aircraft  type  and  route  of  flight 
and  currently  serves  as  a  location  to  keep  a  record  of  clearances  issued. 

This  presentation  of  traffic  information  has  proved  effective  when  the 
controller  is  in  the  loop,  responsible  for  traffic  flow  and  safety.  A  trained 
controller  can  look  at  a  plan  view  display  and  obtain  an  immediate  assessment  of 
the  situation.  In  a  heavily  proceduralized  environment,  the  plan  view  display  alone 
can  provide  almost  a  complete  traffic  picture.  The  information  provided  on  the 
flight  progress  strips  acts  to  complete  the  traffic  picture  and  becomes  more 
important  as  the  number  of  non-standard  operations  increase. 

In  AERA,  a  plan  view  display  continues  to  provide  the  traffic  situation  which 
is  displayed  today  and  electronic  displays  present  the  supplemental  information, 
currently  provided  by  flight  progress  strips.  However,  additional  plan  view  display 
requirements  exist. 

In  the  initial  stages  of  AERA  implementation,  sectors  may  be  the  same  size 
as  today's.  As  controller  workload  begins  to  decrease  due  to  familiarity  with  the 
system  and  increased  aircraft  equippage,  sector  size  can  increase.  This  increase  in 
sector  size  necessitates  that  either  a  portion  of  the  plan  view  display  be  allotted  or 
a  second  display  be  provided  to  allow  isolating  portions  of  the  airspace  for  detailed 
observation. 

The  section  or  display  provided  for  close  observation  can  also  serve  as  a 
clearance  planning  or  flow  display.  Some  examples  of  the  kinds  of  information  that 
might  be  called  up  on  the  planning  display  ares 


120 


A  plan  view  display  of  an  airspace  area  around  a  selected  center  point 
with  a  selected  radius. 

A  projection  of  an  aircraft's  flight  profile  to  a  boundary  for  a  selected 
distance  or  time.  Two  subsets  of  this  display  type  are  likely. 

a.  A  projection  taking  into  account  only  already  issued  clearances 
and  displaying  the  point  of  closest  approach  for  each  aircraft 
projected  to  conflict  with  the  subject  aircraft. 

b.  A  projection  taking  into  account  the  effects  of  planned  clearance 
directives. 

A  pair-wise  display  called  up  by  call  signs  displaying  unresolved  point  of 
closest  approach. 


It  is  envisioned  that  both  the  plan  view  display  and  flight  data  display  area  are 
flexibly  designed  to  allow  quick  identification  of  and  call  up  of  desired  information 
and  ease  of  entry  of  inputs. 

The  appropriate  displays  for  the  additional  information  which  will  be  needed 
by  supervisors  to  support  integrated  flow  management,  severe  weather  avoidance 
and  the  other  functions  outlined  in  Section  6.2.7  has  not  yet  been  defined.  More 
information  will  be  needed  than  that  currently  displayed  to  the  flow  controller,  and 
more  work  is  required  to  define  the  Man-Machine  Interface. 


7.0  AERA  and  Aircrew 


The  aircrew  would  not  experience  any  radical  change  in  procedures  when 
ATC  utilizes  AERA  techniques.  If  an  aircraft  were  DABS  equipped,  clearances 
would  normally  be  provided  by  data  link,  with  or  without  AERA.  Aircraft  could 
still  be  provided  with  VHF  computer-generated  broadcast  clearances  to  preserve 
the  information  provided  by  the  voice  party  line.  Aircrews  would  hopefully  acknow 
ledge  clearances  digitally  if  DABS  equipped.  If  equipped  only  with  VHF  communi¬ 
cations,  it  is  hoped  aircrews  would  acknowledge  computer- voice  clearances 
digitally  utilizing  the  ATCRBS  SPI  pulse  or  a  touch-tone  adapter  to  the  VHF 
microphone. 

The  aircrew  should  have  greater  flexibility,  once  AERA  is  implemented,  in 
selecting  and  being  allowed  to  fly  their  preferred  routes  and  altitude  profiles  with 
a  minimum  of  procedural  deviations.  Flight  plan  requests  based  on  flight 
management  computers  are  likely  to  be  honored  since  AERA  trajectory  profiles  are 
based  on  down-linked  or  nearly  equivalent  data.  Furthermore,  AERA  can  safely 
monitor  and  control  crossing  and  transitioning  flights  without  clearing  major 
airspaces  below  or  above  the  aircraft  and  with  reasonable  time  buffers  on  shared 
airspace,  so  that  direct  routings  at  optimum  altitudes  are  routinely  available  unless 
traffic  density  is  exceptionally  high. 

The  aircrew  should  experience  fewer  holds  when  the  AERA  system  is  being 
used.  They  may,  however,  experience  more  en  route  speed  adjustments  in  order  to 
avoid  downstream  holds  or  S  turns.  AERA's  superior  planning  capability,  which 
reaches  into  TRACON  airspace,  provides  this  improved  metering  capability. 

AERA,  in  conjunction  with  the  9020  replacement  system,  is  able  to  provide 
the  aircrew  with  many  services  depending  on  the  equippage  in  the  aircraft. 
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We  assume  that  no  aircraft  can  operate  within  the  AERA  control  region 
without  a  minimum  set  of  equipment:  a  transponder,  VOR  or  VOR-DME  navi¬ 
gation,  and  a  VHF  transceiver.  The  set  of  AERA  services  provided  to  these 
minimally  equipped  users  i*  different  than  that  received  by  those  fully  equipped. 
For  example,  if  the  transponder  is  not  altitude-encoded,  than  the  aircrew  must 
provide  the  controller  with  altitude  read-outs,  adding  to  the  work  load  of  both 
aircrew  and  controller.  The  minimum-equipped  users  can  receive  only  limited 
weather  data  over  the  radio  as  compared  to  complete  weather  displays  transmitted 
by  data  link.  Proximate  traffic  can  only  be  provided  verbally  rather  than  in 
cockpit  displays  formatted  by  AERA  and  transmitted  by  data  link.  They  receive 
clearances  via  radio  instead  of  over  the  the  data  link.  In  short,  the  minimum- 
equipped  users  limit  the  productivity  of  AERA,  increase  their  own  workload  and 
generally  lower  the  level  of  services  that  can  be  provided.  But  AERA  can 
accommodate  them. 

DABS  data  link  cures  most  of  these  problems  by  providing  a  communications 
channel  across  which  clearance,  traffic,  weather,  and  other  kinds  of  information 
may  be  transmitted.  Pilots  can  request  information  and  have  it  delivered  to  suit 
their  operational  needs.  A  most  positive  feature  of  data  link  is  the  unambigious 
transmission  and  acknowledgement  of  clearances;  a  time  consuming  and  error- 
prone  activity  in  today's  system. 

In  addition  of  a  flight  management  computer,  which  may  be  coupled  to  the 
aircraft's  control  surfaces  and  fuel  management  system,  when  used  with  the  area 
navigation  capability,  allows  the  acceptance  and  use  of  extremely  well-defined 
flight  profiles.  This  allows  the  aircraft  to  fly  whatever  routes  are  desired  in  a 
precise  manner.  This  allows  the  pilot  to  optimize  the  aircraft's  profile  while  in¬ 
flight,  changing  strategies  as  the  situation  warrants. 

AERA  would  lead  to  a  noticeable  increase  in  the  quantity  and  quality  of  data 
exchanged  between  the  aircrew  and  the  ground  control  system. 
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8.0  Telecommunication  Requirements  for  AERA 

FAA  is  currently  engaged  in  the  development  of  an  evolutionary  new  NAS 
Telecommunications  System  which  will  include  a  number  of  enhancements  to  the 
current  system.  The  present  FAA  voice  and  data  communications  system  has 
evolved  over  several  decades.  While  it  is  generally  considered  to  be  adequate  for 
today's  manual  and  limited  semiautomatic  environment,  it  is  costly  to  maintain  and 
will  not  meet  the  projected  requirements  of  the  1985,  and  beyond,  operational 
environment,  including  new  requirements  such  as  may  evolve  from  the  AERA 
program. 

The  telecommunications  system  includes  voice  and  data  circuits  for  ground- 
air-ground  and  ground-ground  communications  between  aircraft,  centers,  ter¬ 
minals,  remote  radio  and  surveillance  sites,  Flight  Service  Stations  and  various 
FAA  national  centers,  such  as  for  weather. 

Studies  of  future  communication  requirements  have  identified  an  integrated 
concept  for  evolutionary  development  of  subsystems  to  get  the  best  benefits  and 
capabilities  of  shared  facilities,  networks  and  switching.  In  conjunction  with  other 
ATC  improvement  programs,  such  as  NAS  9020  replacement  (9020R),  FSS  auto¬ 
mation,  DABS  data  link  and  AERA,  FAA  is  developing  and  implementing  several 
major  communications  upgrades. 

One  of  these  is  the  Voice  Switching  and  Control  System  (VSCS),  which  will 
include  upgraded  versions  of  the  present  Radio  Communications  Subsystem  (RCS) 
and  the  Voice  Communications  Subsystem  (VCS).  The  VSCS  will  meet  the  future 
ground-air-ground  and  ground-ground  voice  control  requirements  for  ARTCCs  and 
FSSs  while  being  supplemented  by  the  DABS  data  communication  system.  Further 
enhancements  may  be  required  for  non-voice  control  communications  (e.g.,  VHF 
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tone  encoding  option),  automated  surveillance  and  other  AERA  requirements  for 
com  munications. 

Many  data  networks  currently  used  in  FAA  are  being  replaced  by  the  new 
NAD1N.  The  NADIN  will  initially  be  centered  on  two  interconnected  switches, 
located  at  Atlanta  and  Salt  Lake  City,  and  will  provide  data  concentrators  at  all 
twenty  ARTCC  centers.  The  NADIN  enhancement  program  will  extend  this  so  that 
eventually  the  centers  will  become  more  fully  interconnected  and  each  concen¬ 
trator  will  become  a  switch;  Thus,  before  the  AERA  time  frame  the  capability  will 
exist  for  full  direct  center-to-center  transfer  of  data  traffic  and  alternate  routing 
in  case  of  node  failure. 

It  is  expected  that  VSCS  and  NADIN  will  form  the  backbone  of  the  FAA 
integrated  NAS  telecommunications  system. 

8.1  AERA  Ground-Ground  Communication  Requirements 

In  order  for  the  AERA  system  to  perform  its  functions  it  must  receive 
surveillance  and  communication  inputs  from  DABS,  ATCRBS  and  the  RCAG  sites. 
As  discussed  these  en  route  data  input  requirements  are  and  will  be  met  by  the 
FAA  independent  of  AERA  since  the  en  route  center  requires  this  information  to 
carry  out  its  functions. 

AERA,  however,  has  additional  communication  requirements  which  are 
caused  by  backup  requirements  for  non-recoverable  AERA  hardware  or  software 
failures,  as  well  as  for  catastrophic  failures. 
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As  discussed  in  Section  4  catastrophic  failure  will  require  as  a  minimum: 
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•  Transmission  of  backup  clearances  from  the  RCAG  and  the  DABS  sites 
to  affected  aircraft. 

•  Transmission  of  backup  clearance  plans  from  each  center  to  its  backup 
locations. 

•  Communication  capability  at  backup  facilities  to  support  the  stabilizing 
process. 

The  center-to-center  communications  capability  can  be  realized  by  utilizing 
planned  NADIN  center-to-center  communication  linkages.  However,  the  buffering 
of  backup  clearances  at  DABS  and  RCAG  sites,  together  with  the  logic  for  knowing 
when  to  transmit  the  backup  clearance  plans,  is  a  new  FAA  communication 
requirement. 

The  requirement  that  RCAG  sites  be  connected  to  adjacent  centers  or 
TRACONs,  in  case  of  catastrophic  failure,  is  a  new  requirement  for  FAA 
communications  if  there  is  no  overlapping  coverage. 

If  any  of  the  three  options  beyond  the  minimum  recovery  concept,  presented 
in  Section  4.3.1,  are  exercised  to  support  a  catastrophic  failure,  multipoint  linkage 
of  existing  ATCRBS  and  the  newer  DABS  sites  to  primary  centers  and  their 
backups  become  a  requirement.  Since  several  of  the  existing  sites  support  two 
existing  centers,  it  is  not  clear  how  costly  or  how  many  additional  surveillance 
sites  have  to  have  multiple  destinations  in  order  to  satisfy  this  backup  surveillance 
option. 

In  case  of  non-recover  able  AERA  hardware  or  software  failure,  there  is  an 
option  in  design  which  utilizes  adjacent  center  computers  to  perform  tasks  for  the 
affected  center  and  communicate  this  data  between  centers  so  that  control 


126 


remains  with  the  control  managers  of  the  affected  center.  In  this  case, 
surveillance  data  can  be  relayed  together  with  other  digital  input  data  to  the 
adjacent  centers  where  such  data  can  be  processed  and  tactical  plans  relayed  back 
to  the  affected  center  for  evaluation  and  release.  This  option,  if  exercised,  will 
not  generate  any  new  communication  hardware  requirement  on  FAA  if  the  planned 
NADIN  system  is  implemented. 

8.2  Ground-Air-Ground  Requirements 

It  is  anticipated  that  the  presently  planned  communications  capabilities  will 
meet  AERA  requirements  for  DABS  data  link  equipped  aircraft.  However,  for  non- 
DABS  data  link  equipped  aircraft  some  additional  communications  capability  would 
improve  AERA  productivity  and  is  desirable,  but  not  necessary. 

As  an  aircraft  flys  through  an  AERA  Planning  Region,  it  moves  from  sector 
to  sector,  and  concurrently  its  line-of-sight  communications  zone  moves  from 
ground  radio  to  ground  radio  site.  At  appropriate  times,  the  center  instructs  the 
aircraft  to  change  its  frequency  so  as  to  communicate  via  different  ground  radio 
sites. 


For  a  DABS  data  link  equipped  aircraft,  the  ATC  instruction  to  change 
frequency  and  the  aircraft  acknowledgement  can  be  accomplished  automatically 
(AERA  knows  aircraft  position  and  frequency  change  boundaries)  via  data  link 
without  controller  or  pilot  intervention.  Communications  planning  can  support  all 
requirements  for  this  case. 

For  a  non-DABS  data-link  equipped  aircraft,  the  ATC  instruction  must  reach 
the  pilot's  ears  and  he  must  acknowledge  overtly.  If  controller  productivity  is  to  be 
maintained  in  AERA,  it  is  clear,  as  the  above  example  illustrates,  that  a  VHF  radio 
tone  encoding  option  would  be  helpful.  Technology  can  provide  a  computer- 
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generated  voice  command  capability  that  FAA  can  utilize  to  meet  the  uplink 
requirement  in  the  AERA  time  frame  without  controller  intervention.  When  an 
automated  computer -generated  voice  command  capability  is  utilized  on  the 
ground-air  link,  a  means  for  automatic  acknowledgement  becomes  desirable.  A 
pilot-actuated  device  which  generates  specific  signals  easily  demodulated  and 
decoded  on  the  ground  is  a  possible  approach.* 

There  are  two  options  for  digital  pilot-activated  devices.  The  first  utilizes 
ATCRBS,  while  the  second  requires  the  purchase  of  a  discrete  tone  keying  device 
adaptable  to  the  pilot's  microphone  and  analogous  to  the  miniaturized  telephone 
tone  key  adapters  now  on  the  market  for  modifying  a  dial  telephone  to  touch  tone 
operation.  The  touch  tone  adapter  could  be  designed  to  incorporate  a  digital 
transmission  of  aircraft  identity,  as  well  as  acknowledgement. 

The  use  of  the  special  position  identification  (SPI)  button  on  ATCRBS  is 
attractive  since  there  is  no  additional  cost  for  the  transponder  equipped  aircraft. 
This  button  places  an  additional  pulse  into  a  Mode  A  or  C  reply  at  4.35  y second 
following  the  last  framing  pulse.  Once  the  button  is  set  it  will  stay  set  for  at  least 
15  seconds  and  as  much  as  30  seconds.  Thus,  the  SPI  pulse  is  guaranteed  to  be 
transmitted  on  each  reply  of  the  set  of  interrogations  received  by  the  transponder 
on  en  route  interrogation  scan.  This  technique  is  simple  but  provides  only  an 
acknowledgement  of  a  received  message,  but  no  verification  of  the  message 
content.  In  order  to  improve  the  reliability  of  the  link  a  procedure  could  be 
employed  whereby  the  ground  computer  voice  transmission  is  repeated  twice  and 
where  the  SPI  button  is  set  only  if  both  transmissions,  as  received,  are  identical. 


♦Voice  recognition  machines  on  the  ground  would  be  desirable  since  the  pilot  need 
not  invest  in  any  additional  equipment  and,  by  repeating  back  the  uplink  message  in 
his  acknowledgment,  the  link  can  be  made  extremely  reliable.  These  machines  are 
under  development  for  many  applications  and,  in  particular,  are  of  interest  to  the 
banking  industry.  Thus,  large  dollar  investments  are  being  made  in  this  technology 
and  it  is  expected  that  such  machines  with  limited  capability,  such  as  recognizing 
16  commands,  will  be  commercially  available  in  the  1990s.  However,  such 
machines  normally  have  to  go  through  a  learning  cycle  with  each  individual  user; 
and  given  a  cockpit  noise  background,  it  would  be  very  optimistic  and  somewhat 
unrealistic  to  design  an  FAA  data  link  acknowledgment  system  based  on  a  voice 
recognition  machine  requirement. 
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Tone  keying  devices  have  been  successfully  applied  to  other  applications  and 
because  of  their  relative  low  cost  (i.e.,  $25  to  $30)  are  attractive  for  this 
application.  The  technique  is  sufficiently  attractive  that  FAA  should  explore  this 
technology  to  explore  human  factor  problems  and  various  techniques  to  provide 
aircraft  identity. 

The  use  of  computer-generated  voice  commands  at  VHF  does  not  eliminate 
controller-pilot  voice  communications,  but  rather  reduces  the  controller  voice 
communication  workload.  Thus  a  controller  is  responsible  for  larger  numbers  of 
aircraft  in  larger  regions  of  airspace  than  in  the  existing  ATC  system.  Assuming 
that  the  VHF  frequency  allocations  do  not  change,  the  AERA  design  concept  is 
constrained  in  the  following  ways: 

•  Computer-generated  voice  commands  and  controller  voice  communi¬ 
cations  must  share  a  common  frequency  channel  without  conflict. 

•  A  controller  may  have  to  communicate  with  aircraft  on  several 
different  frequency  channels. 

These  design  requirements  can  be  met  as  described  below: 

With  respect  to  the  sharing  of  the  channel,  it  is  noted  that  computer¬ 
generated  voice  commands  originate  as  digital  signals  which  can  be  easily  buffered. 
Therefore,  the  AERA  controller  can  resolve  conflicts  by  pressing  a  button  to 
preempt  the  channel  and  buffer  digital  messages  so  that  they  are  not  lost.  When 
there  are  no  conflicts,  then  either  the  controller  or  the  computer  can  access  the 
channel. 
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APPENDIX  1* 

An  Incremental  Approach  to  AERA  Implementation 


Motivations  for  an  Incremental  Approach:  Evolution  to  a  system  like  AERA 
will  be  guided  and  paced  by  several  factors,  including  the  following: 

1.  The  Desire  to  Obtain  Operational  Benefits  Before  AERA  is  Fully 
Developed:  The  system  envisioned  by  the  AERA  concept  will  take 
many  years  of  intensive  development  and  experimentation  before  it  is 
fully  realized  in  practice.  Some  functional  capabilities  will  take  longer 
to  achieve  than  others.  In  order  to  make  functional  improvements  to 
the  existing  ATC  system  before  full  AERA  is  developed,  it  would  be 
desirable  to  partition  the  AERA  functional  design  into  operationally 
useful  increments,  to  develop  them  in  some  desirable  sequence,  and  to 
package  them  for  evolutionary  deployment. 

With  some  foresight,  good  overall  system  design,  and  well-defined 
interfaces  between  increments,  it  should  prove  practical  to  do  this  in  a 
manner  which  satisfies  certain  technological  constraints,  ATC 
operational  needs,  and  reasonable  budgetary  constraints.  Actual 
deployment  decisions  would  be  keyed  to  FAA's  confidence  in  each 
incremental  product  as  it  emerges  from  the  development  and  experi¬ 
mental  evaluation  process  for  AERA. 

2.  The  Need  to  Maintain  Continuity  of  ATC  Services:  Civil  ATC  in  the 
United  States  is  a  24  hour-a-day,  7  days-a-week,  operation.  ATC 
services  as  seen  by  the  users  of  the  airspace  must  remain  available  and 


•The  AERA  concept  team  has  not  reviewed  as  a  group  the  contents  of  this 
appendix. 


be  highly  reliable.  The  system  upgrading  process  will  have  to  be 
carefully  planned  and  conducted  to  avoid  disruptions  to  service. 

Proven  backup  systems  and  procedures,  including  the  possibility  of 
having  to  revert  to  the  current  NAS  Stage  A  system  during  the 
transition,  will  have  to  be  in  place  and  working  to  ensure  safety  at  all 
times.  The  incremental  approach  may  ease  the  problems  of  assuring 
adequate  backups  by  (a)  reducing  the  rate  of  exposure  to  unfamiliar 
systems  and  procedures;  and  by  (b)  making  reversion  back  to  familiar 
systems  and  procedures  in  the  initial  stages  easier. 

The  Need  to  Train  Personnel  and  to  Make  Changes:  About  10,000  air 
traffic  specialists  and  several  thousand  system  maintenance  specialists 
are  currently  employed  to  operate  and  maintain  the  en  route  portion  of 
the  ATC  system. 

Before  new  systems  and  procedures  can  be  introduced,  key  personnel 
will  have  to  be  trained  in  their  use.  These  key  personnel  will 
undoubtedly  uncover  problems  that  lead  to  design  or  procedural 
changes.  They  will  also  have  to  carry  out  the  planning  for  the 
conversion  of  their  individual  facilities,  and  they  will  have  to  train 
others  so  that  the  cadre  of  skilled  staff  can  continue  to  grow. 
Sufficient  time  must  be  allowed  for  these  things  to  be  worked  out  in  an 
orderly  fashion.  The  incremental  approach  promises  to  make  this 
process  more  understandable,  more  manageable,  and  therefore,  less 
risky. 


The  Needs  of  the  Airspace  Users  versus  Budgetary  Constraints:  The 
needs  of  those  who  buy,  equip,  and  upgrade  the  aircraft  that  operate 
within  the  ATC  system  are  subject  to  benefits  versus  cost  arguments 


■Of?* '  «■ 


131 


and  budgetary  limits.  Aircraft  equippage  is  therefore  related  to  the 
economic  well-being  and  priorities  of  the  operators.  Aircraft  equippage 
also  influences  the  direction  and  pace  of  ATC  facility  upgrading.  Fleet 
equippage  with,  say,  DABS  data  link  and  airborne  systems  to  use  it  may 
either  lead  or  lag  the  ATC  system's  ability  to  exchange  data  with 
aircraft.  But  since  equippage,  except  for  safety  requirements,  will 
likely  remain  voluntary  for  years  to  come,  the  level  of  equippage  will 
not  be  uniform  among  those  who  continue  to  receive  ATC  services.  The 
incremental  approach  to  AERA  could  reflect  this  evolutionary  nature  of 
fleet  equippage. 

Given  these  factors,  it  is  prudent  to  plan  for  incremental  implementation  of 
an  ATC  system  with  AERA-like  features. 
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APPENDIX  2 

ARTCC/TRACON  Interactions  in  the  Current  ATC  System 


In  the  current  ATC  system,  the  authority  for  planning  and  controlling 
instrument  flight  movements  between  airports  is  vested  primarily  in  the  ATC 
facilities  known  as  Air  Route  Traffic  Control  Centers  (ARTCCs  or  "centers”  for 
short).  However,  in  the  vicinity  of  busy  airports,  there  are  unique  problems  to  be 
solved  in  merging  and  properly  spacing  arrivals  to  a  common  final  approach  course, 
and  in  interleaving  departures  with  those  arrivals,  getting  them  out  of  the 
immediate  area,  and  safely  established  on  the  proper  outbound  heading.  Because  of 
the  specialized  nature  of  these  problems,  each  center  typically  delegates  its 
control  authority  for  handling  the  approaches  to  potentially  busy  airports  to 
specialized  "approach  control  facilities."  Each  approach  control  facility  also 
handles  the  approaches  to  all  secondary  airports  within  the  vicinity  of  the  primary 
airport. 

To  delegate  this  control  responsibility,  center  representatives  meet  with 
approach  control  facility  representatives  to  jointly  agree  upon  a  common  airspace 
boundary  and  set  of  procedures  between  the  two  facilities.  That  boundary,  and  the 
procedures  for  coordinating  flight  movements  across  that  boundary  under  a  variety 
of  conditions,  is  formalized  in  a  Letter-of-Agreement.  The  degree  to  which  that 
agreement  imposes  constraints  on  how  flights  may  cross  the  boundary  depends,  in 
part,  on  the  amount  of  traffic  potentially  involved.  It  also  depends  on  the 
uncertainties  and  workload  associated  with  planning  and  coordinating  clearances  in 
advance  across  that  boundary. 
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Those  approach  control  facilities  which  have  their  own  fast-scan  beacon/ 
radar  surveillance  systems  (Airport  Surveillance  Radars,  or  "ASRs"  for  short)  are 
referred  to  in  this  document  as  Terminal  Radar  Approach  Control  (TRACON) 
facilities.  These  TRACONs,  and  the  airport  towers  which  control  the  air  traffic 
local  to  and  on  the  surface  of  the  airport,  are  collectively  referred  to  as  "terminal 
facilities"  or  "TRACON/Towers."  One  TRACON  may  serve  several  airports,  either 
controlled  (the  airport  has  an  ATC  tower)  or  uncontrolled  (the  airport  has  no  ATC 
tower).  Similarly,  a  non-radar  approach  control  facility  may  be  delegated  airspace 
within  which  to  organize  instrument  flights  to/from  one  or  more  airports  using  non¬ 
radar  procedures. 


FAA  now  operates  all  approach  control  facilities  that  serve  civil  airports, 
joint-use  military  bases  and  airfields  in  the  United  States.  Various  names  are  used 
operationally  which  reflect  both  the  facility's  primary  mission  and  whether  or  not 
ASR-based  ("radar")  services  are  provided.  For  airports  with  radar  approach 
control  services  provided  by  a  special  facility: 


Main  Mission 


Name  (Acronym) 


Civil 

Air  Force 
Navy 


Terminal  Radar  Approach  Control  (TRACON) 
Radar  Approach  Control  (RAPCON) 

Radar  Air  Traffic  Control  Facility  (RATCF) 


For  airports  without  the  coverage  of  a  fast-scanning  (4  seconds)  Airport 
Surveillance  Radar  (ASR),  IFR  approach  control  services  (if  provided  at  all)  may  be 
procedurally  provided  by  non-radar  approach  control  positions  in  some  convenient 
facility,  typically  an  airport  ATC  tower.  Alternatively,  radar  approach  services 
can  be  provided  by  a  radar  controller  in  the  overlying  ARTCC.  Since  the 
surveillance  approach  control  may  be  limited  by  the  relatively  slow  scan  (10  to  12 
seconds)  of  the  ARTCC's  Air  Route  Surveillance  Radar/ARSR  systems  and  by  the 
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remoteness  of  that  long  range  radar  relative  to  the  airport,  the  quality  of  the  radar 
services  to  such  airports  can  also  be  limited.  Typically,  such  operations  reflect  a 
mix  of  radar  and  non-radar  procedures. 

To  get  a  better  sense  of  what  it  means  for  an  ARTCC  to  delegate  airspace  to 
several  approach  control  facilities  within  the  center  boundary,  consider  the 
following  two  examples: 

1.  The  New  York  center  delegates  airspace  to  the  "New  York  Common 
IFR  Room"  (or  "NYCIFRR",  soon  to  be  re-opened  and  re-organized  as 
the  "New  York  TRACON")  and  13  other  approach  control  facilities 
within  the  center's  boundary.  The  delegated  airspace  to  the  NYCIFRR 
encloses  the  approaches  to  the  three  major  airports  (Kennedy, 
LaGuardia,  and  Newark)  and  their  satellites.  Vertically,  it  extends  to 
altitudes  as  high  as  17,000  feet  MSL.  Only  a  very  small  fraction  of  the 
airspace  below  7,000  feet  within  the  center's  boundary  has  not  been 
delegated  to  the  NYCIFRR,  or  to  one  of  the  other  approach  control 
facilities. 

The  extent  of  the  horizontal  area  involved  can  be  appreciated  by 
realizing  that  the  following  approach  control  facilities  are  within  the 
New  York  Center's  area: 

Elmira,  New  York 
Dover,  Delaware 
Harrisonburg,  Pennsylvania 

2.  The  Denver  center  delegates  airspace  to  seven  approach  control 
facilities.  Of  these,  three  provide  "radar  services"  (Denver  TRACON, 
Colorado  Springs  TRACON,  and  the  Ellsworth  AFB  RAPCON). 
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APPENDIX  3 

Fuel  Efficiency  Considerations  in  Absorbing  Landing  Delays 


The  fuel  burn  characteristics  of  a  typical  B727-20 0  are  illustrated  in 
Figures  A3- 1  and  A3- 2  for  three  different  kinds  of  airspeed  schedules:  constant  Mach 
(.80,  .82,  .84),  Long  Range  Cruise  (LRC),  and  Maximum  Endurance  Speed  (MES).  In 
particular: 


1.  Long  Range  Cruise  (LRC)  Speed  is  that  operationally  useful  speed  which 
minimizes  fuel  consumption  in  terms  of  pounds  of  fuel  burned  per  mile 
(Figure  A3-1).  Implication:  Use  this  speed  schedule  when  delays  are  not 
expected. 

2.  Maximum  Endurance  Speed  (MES)  is  that  operationally  useful  speed 
which  minimizes  fuel  consumption  in  terms  of  pounds  of  fuel  burned  per 
minute  (Figure  A3-2).  Implication:  Use  this  speed  schedule  when  being 
held  to  absorb  landing  delays. 

The  values  of  these  speed  schedules  in  terms  indicated  airspeed  (IAS)  as  a  function 
of  altitude  are  illustrated  in  Figure  A3-3. 

Thus,  if  no  landing  delays  are  expected,  the  LRC  speed  schedule  is  (by 
definition)  the  most  fuel-efficient  to  fly  at  any  altitude.  However,  note  that  fuel 
consumption  per  mile  at  LRC  speed  goes  through  a  definite  minimum  in  the 
vicinity  of  FL350  for  a  160,000  pound  B727-200  under  standard  (ISA)  atmospheric 
conditions.  The  optimal  altitude  for  a  heavier  B727-200  is  lower.  For  example: 


175,000  pounds,  FL330 
200,000  pounds,  FL290 
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ALTITUDE  (MOO  FT) 
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Figure  A3-2 


FUEL  CONEUMFTtON  Mil  MINUTE  IN  CRUISE  AT  DIFFERENT  ALTITUDES 
(FOR  A  E727-200  •  110,000  LEE  AND  ZERO  WIND,  ISA) 
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Figure  A3- 3 

STANDARD  AIRSPEED  SCHEDULES  VERSUS  ALTITUDE  AND  INDICATED  AIRSPEED 
(POR  A  B727-200  •  ISO, 000  LBS  AND  ZERO  WIND,  ISA) 
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Fuel  consumption  at  10,500  pounds  of  fuel  per  hour  means  that  the  pilot  of  a 
200,000  pound  B727  might  initially  request  an  assigned  altitude  of  FL290,  but  two 
hours  later  request  a  higher  assignment  to  FL330  to  remain  nearer  his  fuel-optimal 
altitude. 

However,  if  a  landing  delay  must  be  absorbed,  then  the  most  fuel-efficient 
choice  is  to  slow  the  aircraft  down,  if  practical  at  the  current  cruising  altitude, 
and  to  add  whatever  miles  are  necessary  to  absorb  the  delay.  If  the  delay  is 
predicted  early  enough,  slowing  down  to  a  speed  at/above  MES  may  be  sufficient. 
If  not,  path-stretching  or  holding  procedures  must  be  included  to  add  the  necessary 
miles  for  delay  absorption. 

As  illustrated  in  Figure  A3-2  for  a  160,000  pound  B727,  there  is  about  30  knots 
(IAS)  difference  between  the  LRC  and  MES  speeds  at  FL350,  as  compared  to  about 
100  knots  difference  at  10,000  feet  MSL  or  below.  Thus,  the  delay  absorption 
capability  available  through  speed  reduction  decreases  as  altitude  increases. 

Figure  A3-4  illustrates  the  delay  absorption  capability  that  exists  through 
speed  control  as  a  function  of  altitude  for  a  160,000  pound  B727  under  ISA 
conditions  and  zero  wind.  To  determine  the  amount  of  delay  which  can  be  absorbed 
when  reducing  from  LRC  speed  to  MES  using  Figure  A3-4,  take  the  difference 
between  the  two  families  of  curves  shown  for  any  constant  Mach.  For  example, 
the  difference  between  "From  .80  to  MES"  and  "From  .80  to  LRC"  at  FL330  is 
about  one  second  per  nautical  mile.  Thus,  about  two  minutes  of  delay  is  absorbable 
over  a  120  mile  leg  (zero  wind),  if  that  leg  is  flown  at  MES  instead  of  LRC. 


ALTITUDE  (tOOO  FT) 


0 


Figure  A3-4 


SPEED  CONTROL  LABILITY  IN  SECONDS  PER  MILE  AT  DIFFERENT  ALTITUDES 
(FOR  A  B- 727-200  •  1B0.000  LBS  ft  ZERO  WIND,  ISA) 
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It  should  also  be  noted  that  of  the  three  speed  schedules,  the  MES  fuel  burn  is 
the  least  sensitive  to  altitude  variation.  That  is,  while  fuel  consumption  is  always 
minimized  when  the  optimum  altitude  is  flown,  the  fact  that  a  delay  is  taken  at  a 
lower  non-optimum  altitude  does  not  greatly  increase  fuel  consumption,  given  that 
the  aircraft  is  flown  at  MES. 

For  example,  if  a  B727-200  were  flown  at  10,000  feet  pressure  altitude  at 
LRC  speed,  when  its  optimal  altitude  is  33,000  feet,  then  the  penalty  would  be 
about  67  percent  increase  in  fuel  consumption  per  mile.  However,  if  the  aircraft 
were  held  at  10,000  feet  at  MES  to  absorb  an  assigned  delay,  the  penalty  would  be 
only  about  ten  percent  in  fuel  consumption  per  minute,  relative  to  taking  that  same 
delay  at  FL330.  See  Figure  A3-5. 


Figure  A3- 5 

FUEL  CONSUMPTION  AT  MAXIMUM  ENDURANCE  AND  DIFFERENT  ALTITUDES 
(FOR  A  B-727-200  ft  ZERO  WIND,  ISA) 
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APPENDIX  4 

Strategic  Conflict  Prediction  in  AERA 


In  the  section  entitled  "AERA  System  Description",  the  strategic  planning 
function  of  "conflict  prediction"  was  briefly  described.  The  purpose  of  this 
appendix  is  to  explain  certain  aspects  of  this  function  in  more  detail  and,  in 
particular,  to  explain  the  output  of  the  prediction  function  called  "conflict  boxes." 
These  boxes  are  data  structures  designed  primarily  for  consumption  by  the  conflict 
resolution  function.  The  function  of  conflict  resolution  is  performed  either 
automatically  by  the  AERA  system  itself  or  semi-automatically  by  an  air  traffic 
specialist  working  with  an  interactive  AERA  planning  display. 

Overview:  The  function  of  the  strategic  conflict  predictor  is  to  find  and 
identify  those  places  where  planned  flight  trajectories  potentially  interfere  with 
one  another,  or  with  some  other  obstacle  (e.g.,  a  severe  weather  cell  or  a  denied 
Military  Operating  Area).  It  does  this  by  taking  a  subject  trajectory  and  running 
down  its  length  in  search  of  other  trajectories,  or  other  obstacles,  which  are  not 
naturally  segregated  from  the  subject  by  at  least  one  of  the  following:  obvious 
lateral  (route)  differences,  altitude  differences,  or  time  differences.  Those  object 
trajectories  not  obviously  separated  from  the  subject  trajectory  are  potential 
conflicts  which  may  require  resolution  planning  to  ensure  separation. 

The  predictor’s  gross  filter  is  the  function  which  discards  all  of  the 
trajectories,  or  other  obstacles,  which  are  obviously  not  in  conflict  with  the 
subject's  trajectory,  either  as  given  or  as  it  might  be  modified  by  the  conflict 
resolution  function.  One  design  goal  is  to  find  very  efficient  gross  filtering 
techniques  so  that  the  performance  of  the  AERA  system  is  not  affected  by 
workloads  involving,  say,  500  to  1,000  planned  trajectories. 
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The  predictor's  fine  filter  is  the  function  which  decides  whether  any 
remaining  potential  conflict  found  for  a  given  subject  will  occur  with  high  enough 
probability,  or  near  enough  in  the  future,  to  warrant  declaring  it  "possible"  or 
"real"  for  the  purposes  of  conflict  resolution  planning.  A  "possible  conflict"  is  one 
for  which  it  is  predicted  that  horizontal  separation  will  be  lost  over  some  interval. 
A  "real  conflict"  is  one  for  which  it  is  predicted  that  both  horizontal  separation  and 
vertical  separation  will  be  lost  over  some  interval.  Such  conflicts  are  the  outputs 
of  the  conflict  prediction  function. 

The  predictor's  outputs  are  stored  for  use  by  the  resolution  planning  function 
in  a  data  structure  called  conflict  box.  Conflict  box  is  a  linked  list  of  individual 
boxes  which  contain  the  data  characterizing  the  conflicts  which  deserve  the 
attention  of  the  conflict  resolution  function  immediately. 

Conflict  Boxes  Illustrated:  Figure  A4-1  illustrates  the  concept.  The  planned 
trajectories  for  an  eastbound  arrival  (solid  lines)  and  a  northeast  bound  overflight 
(dotted  lines)  are  shown  in  both  horizontal  profile  (the  "plan  view")  and  in  vertical 
profile  (the  "vertical  view").  Successive  predicted  positions  for  the  "subject" 
arrival  are  marked  with  an  "S",  and  the  corresponding  predicted  positions  for  the 
"object"  overflight  are  marked  with  an  "O".  The  "conflict  box"  for  the  object 
aircraft,  relative  to  the  subject  aircraft's  vertical  profile,  is  the  rectangle  with  the 
horizontal  dimension  marked  "vertical  separation  required"  and  with  the  vertical 
dimension  marked  "±1,000  feet". 

The  box  exists  because  the  currently  predicted  minimum  miss  distance  in  the 
horizontal  plane  (dm)  is  less  than  the  current  value  of  the  minimum  separation 
(SEPM)  function.  In  this  particular  illustration,  its  horizontal  dimension  is 
determined  by  where  the  predicted  violations  of  SEPM  first  and  last  occur.  Its 
vertical  dimension  is  determined  by  the  altitude  profile  of  the  object  aircraft  and 
the  minimum  separation  function  applicable  to  that  profile  in  the  vertical  domain 
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(SEPZ).  In  this  case,  it  is  assumed  that  the  value  of  SEPZ  is  "1,000  feet"  above  and 
below  the  object's  vertical  profile. 

The  conflict  is  defined  as  "real"  if  the  subject's  profile  penetrates  the 
conflici  box  of  the  object  aircraft.  The  conflict  is  defined  as  "possible"  if  the  box 
exists  (i.e.,  SEPM  is  violated),  but  the  vertical  profile  for  the  subject  bypasses  the 
box  above  or  below.  In  the  case  illustrated,  below  the  box  means  that  the  pilot 
plans  to,  or  will  be  cleared  to,  begin  the  descent  early  enough  so  that  vertical 
separation  is  regained  before  horizontal  separation  is  predicted  to  be  lost.  Passage 
above  the  box  means  that  the  pilot  will  be  cleared  to  begin  the  descent  only  after 
the  two  aircraft  have  actually  passed  through  the  intersection  and  their  track  data 
indicates  that  horizontal  separation  has  been  restored.  In  the  early  descent  case, 
an  altitude  crossing  restriction  would  be  appended  to  the  descent  clearance,  in 
order  to  ensure  that  the  top-of-descent  point  and  rate  of  descent  are  sufficient 
avoid  penetrating  the  box. 

In  this  particular  illustration,  it  is  assumed  the  subject  aircraft  w ill  also  be 
the  aircraft  selected  to  yield  the  right-of-way,  consequently,  it  is  also  referred  to 
as  the  "burdened  aircraft".  The  object  aircraft  would  therefore  be  granted  the 
right-of-way  and  is  therefore  referred  to  as  the  "privileged  aircraft".  In  general, 
the  term  "subject"  identifies  which  flight's  trajectory  is  being  examined  for 
conflicts,  and  the  term  "burdened"  identifies  which  flight's  trajectory  will  be 
replanned  to  resolve  any  conflicts  found.  Any  combination  is  possible;  i.e.,  the 
"subject"  of  a  conflict  probe  may  be  picked  as  the  "privileged"  flight  in  a  particular 
conflict.  This  means  that  the  resolution  planner  would  select  the  other  flight  (the 
"burdened"  one)  as  its  subject  for  replanning,  and  the  privileged  flight  would  now 
become  the  object  to  be  avoided  by  the  former's  replanned  trajectory. 

The  Minimum  Separation  Function:  This  function  is  used  to  compute  the 
value  of  the  parameter  SEPM.  If  the  predicted  minimum  miss  distance  is  less  than 
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SEPM,  then  a  conflict  in  the  horizontal  plane  is  declared.  If  it  is  equal  to  or 
greater  than  SEPM,  then  the  trajectories  are  declared  to  be  safely  separated.  The 
parameter  SEPM  is  made  a  variable  in  order  to  tune  the  performance  of  the  fine 
filter  with  regard  to  the  tradeoff  between  falsely  predicting  conflicts  (which  leads 
to  unnecessary  replanning)  and  missing  the  opportunity  to  predict  real  conflicts 
(which  can  result  in  insufficient  lead  time  for  replanning). 

The  function  is  primarily  dependent  upon  the  estimated  time  to  closest 
approach  for  a  given  conflict: 

For  near  conflicts  (e.g.,  within  an  estimated  ten  minutes  of  closest  approach), 
SEPM  is  chosen  to  be  larger  than  the  official  separation  standard  by  an 
amount  sufficient  to  account  for  the  uncertainties  of  prediction.  That  is,  if 
the  predicted  miss  distance  is  greater  than  SEPM,  then  the  probability  that 
the  actual  miss  distance  will  be  less  than  the  separation  standard  is 
practically  zero. 

For  conflicts  farther  out  (e.g.,  greater  than  an  estimated  ten  minutes  to 
closest  approach),  SEPM  is  chosen  so  as  to  satisfy  some  criteria  that  the 
probability  of  a  false  conflict  prediction  should  be  less  than  some  established 
threshold.  Far  enough  out  and  the  value  of  SEPM  drops  to  zero,  meaning  that 
any  prediction  of  conflict  that  far  away  is  unreliable. 

Each  trajectory  is  submitted  for  re-prediction  whenever  significant  devi¬ 
ations  from  predicted  flight  progress  are  detected,  whenever  planning  is  required, 
or  periodically  (every  5  minutes,  on  the  average)  in  the  absence  of  progress 
deviations  or  replanning  events.  Thus  the  conflict-free  horizon  for  each  flight  is 
incrementally  pushed  ahead  as  the  flight  progresses  through  the  system.  A  design 
objective  is  to  maintain  10  to  20  minutes  of  conflict-free  airspace  in  front  of  each 
controlled  flight's  current  position. 
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Generalizing  the  Conflict  Box  Concept;  In  the  previous  illustration,  the 
horizontal  dimension  of  the  conflict  box  was  set  by  the  predicted  locations  of  the 
first  and  last  violations  of  SEPM  in  a  given  conflict.  This  suffices  as  an 
explanation  of  why  the  conflict  box  currently  exists  and  of  how  severe  the  violation 
of  SEPM  is  (whether  near  collision  or  near  safe  passage).  But  for  other  purposes, 
this  definition  may  be  extended. 

In  general,  the  dimensions  of  the  box  depend  upon  the  purpose  to  which  the 
box  is  put.  For  example,  if  it  were  used  to: 

1.  Explain  why  the  box  exists,  then  the  dimensions  are  set  by  SEPM  and 
SEPZ. 

2.  Define  the  airspace  between  the  expected  first  and  last  violation  of 
official  separation  standards,  then  the  dimensions  are  set  by  those 
separation  standards  (e.g.,  five  miles  and  1,000  feet). 

3.  Define  the  airspace  between  the  first  and  last  violations  of  some  other 
definitions  of  protected  airspace  to  be  avoided,  then  the  dimensions  of 
the  box  would  be  set  by  those  definitions.  Figure  A4-2  illustrates 
some  alternatives: 

"t"  minutes  to  violation  of  "d"  miles 
"t"  minutes  to  predicted  closest  approach 
"d"  miles  and  closing 
"d"  miles  and  opening 

These  are  trivial  additions  to  the  definition  of  the  conflict  box  data  structure,  as 
explained  next. 
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Conflict  Boxes  as  Data  Structures:  The  conflict  box(es)  for  any  single 
encounter  includes,  but  is  not  limited  to,  the  following  kinds  of  data: 

General  Conflict  Descriptors: 

•  The  cause  of  the  conflict,  for  example: 

1.  Another  aircraft's  planned  trajectory 

2.  A  denied  sector  boundary 

3.  A  denied  shelf  boundary 

4.  A  denied  restricted  area  boundary 

5.  A  denied  holding  pattern  boundary 

•  The  identities  of  the  flight(s)  involved. 

•  The  value  of  SEPM  used  in  declaring  the  conflict. 

•  The  currently  predicted  minimum  miss  distance. 
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APPENDIX  5 

Strategic  Delay  Prediction  in  AERA 


In  the  section  entitled  "AERA  System  Description",  the  strategic  planning 
function  of  delay  prediction  was  briefly  described.  The  purpose  of  this  appendix  is 
to  explore  certain  aspects  of  this  function  and  its  interfaces  with  the  outside  world 
in  more  detail,  specifically: 

1.  Alternative  methods  for  computing  a  flow  rate  restriction  to  a 
saturable  airport  with  one  or  more  active  arrival  runways. 

2.  Delay  discounting  to  ensure  that  the  delay  assigned  to  any  en  route 
arrival  is  not  excessive  because  of  inherent  errors  in  the  delay 
prediction  process. 

Three  Alternative  Methods  for  Computing  an  En  Route  Metering  Restriction: 
The  three  methods  have  been  referred  to  elsewhere  (Reference  1)  as: 

In-Trail  Spacing  (ITS) 

Arrival  Rate  Metering  (ARM) 

Time  of  Arrival  (TO A) 

The  relative  performance  of  each  of  these  methods  has  been  a  subject  of 
study  for  several  years,  using  data  from  both  computer  simulations  and  from 
observations  of  actual  traffic  at  selected  field  sites  (see  References  1  through  5). 
Though  a  review  of  the  results  of  these  studies  is  beyond  the  scope  of  this 
appendix,  their  results  seem  to  indicate  that: 
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1.  In  terms  of  relative  ease  of  implementation  in  the  context  of  the 
current  NAS  Stage  A  en  route  system,  the  order  is: 

ITS  (currently  in  use  in  most  ARTCCs) 

ARM  (early  prototype  systems  are  currently  in  use  at  least  in  the 
Denver  and  Fort  Worth  ARTCCs) 

TO  A  (not  planned  for  use  in  any  facility  yet) 

The  basic  reason  for  this  is  that  computer-based  scheduling  aids  are 
required  to  implement  ARM  and  TOA,  and  except  for  two  early 
prototypes,  these  are  still  under  development. 

2.  In  terms  of  the  expected  relative  level  of  performance,  the  order  is: 

TOA  (most  fuel  efficient) 

ARM 

ITS  (least  fuel  efficient) 

The  reasons  for  this  will  be  apparent  after  each  is  conceptually 
described  and  compared  below. 

Because  of  this  fluid  situation  where  probably  the  best  has  not  yet  been 
developed  and  proven,  the  AERA  system  concept  has  been  designed  to  accept  any 
of  the  three  flow  restriction  methods.  While  TOA  is  preferred,  the  option  for  using 
ARM  or  ITS  is  retained.  A  summary  of  each  technique  follows: 

In-Trail  Spacing  (ITS):  In  the  current  ATC  system,  the  arrival  capacity  (or 
acceptance  limit)  of  a  saturable  airport  is  usually  stated  in  the  form  of  "so  many 
arrivals  per  hour."  This  hourly  limit  is  typically  sub-divided  among  three  or  four 
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established  feeder  fixes,  one  fix  for  each  major  direction  of  inbound  flow. 
Whenever  demand  is  expected  to  exceed  capacity,  the  TRACON  which  serves  the 
airport  is  responsible  for  establishing  the  values  of  the  feeder  fix  acceptance 
limits.  It  is  also  responsible  for  merging  these  several  feeder  fix  flows  into  a 
properly  spaced  landing  sequence,  one  for  each  active  runway.  At  many  locations, 
the  limit  for  each  feeder  fix,  is  translated  into  a  "so  many  miles  in-trail" 
restriction,  based  on  an  assumed  average  ground  speed  for  all  aircraft  in  the  flow. 

For  example,  an  airport  operating  independent  approaches  to  two  parallel 
runways  might  allocate  60  landings  per  hour  to  the  arrival  center  which  feeds  it, 
reserving  any  remaining  runway  capacity  for  departures  and  for  local  VFR  arrivals. 
If  the  expected  demand  via  each  of  the  four  en  route  feeder  fixes  were  evenly 
distributed,  then  this  would  imply  a  15  arrivals  per  hour  restriction  for  each  feeder 
fix,  or  one  arrival  over  the  fix  no  more  than  every  four  minutes  on  the  average.  At 
300  knots  average  ground  speed  in  the  vicinity  of  the  fix,  the  minimum  spacing 
between  successive  arrivals  should  be  5  miles/minute  times  4  minutes  equals  20 

i 

miles  in-trail. 

There  is  typically  one  funnel-shaped  arrival  sector  for  each  feeder  fix.  The 
radar  controller  at  each  arrival  sector  is  responsible  for  merging  the  arriving 
aircraft  for  handoff  to  the  arrival  TRACON.  The  merge  operation  sequences  and 
spaces  these  arrivals  into  a  single  in-trail  stream  over  the  feeder  fix  and  descends 
them  to  the  proper  altitude  for  handoff.  When  an  in-trail  restriction  is  in  effect, 
each  arrival  sector  controller  has  the  responsibility  for  assuring  sufficient  in-trail 
spacing  to  meet  that  restriction  (e.g.,  >20  miles  in-trail).  When  no  restriction  is  in 
effect,  the  spacing  between  successive  arrivals  need  only  be  sufficient  for  safety 
(e.g.,  >5  miles  in  trail). 

Arrival  Rate  Metering  (ARM):  In  the  preceding  example,  the  airport  was 
assumed  capable  of  accepting  60  arrivals  per  hour  from  the  ARTCC,  or  30  arrivals 
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per  hour  per  runway,  assuming  IFR  arrival  loads  are  balanced  on  the  two  runways. 
This  implies  that  the  inter-arrival  interval  to  a  given  runway  should  be  120  seconds 
between  aircraft,  on  the  average.  An  alternative  method  of  en  route  metering  is 
to  develop  a  tentative  landing  schedule  for  each  runway,  based  on  that  average 
interval.  At  the  Fort  Worth  and  Denver  ARTCCs,  the  9020  computer  is  used  to 
compute  a  tentative  landing  schedule  using  the  TRACON's  estimate  of  the  runway 
IFR  acceptance  rate  converted  to  a  time  interval  (e.g.,  120  seconds).  Those  flights 
known  by  the  ARTCC  to  be  inbound  to  the  airport  and  planning  to  arrive  at  the 
runway  during  the  next  half  hour  or  so  are  time-ordered  by  their  calculated  time- 
of-arrivals  at  the  runway.  That  sequence  of  expected  arrivals  is  then  separated  by 
at  least  the  pre-established  inter-arrival  spacing  interval  to  achieve  a  possible 
landing  schedule. 

This  possible  landing  schedule  is  sub-divided  into  several  schedules,  one  for 
each  feeder  fix,  and  the  tentatively  scheduled  arrival  times  at  the  runway  are 
reduced  by  the  expected  average  flying  time  to  the  runway  from  each  feeder  fix. 
The  result  is  a  desired  fix  crossing  time  for  each  arrival  expecting  to  use  that 
feeder  fix.  The  difference  between  that  desired  crossing  time  and  the  currently 
calculated  arrival  time  yields  the  currently  estimated  landing  delay  for  each 
aircraft. 

As  in  the  preceding  case,  one  sector  controller  merges  all  arrivals  to  a  given 
feeder  fix  so  as  to  meet  the  feeder  fix  restriction,  which  in  this  case  is  posted  as  a 
sequence  of  desired  feeder  fix  crossing  times. 

This  method  has  the  advantages  of  automatically  compensating  for  load 
imbalances  between  feeder  fixes  and  of  synchronizing  somewhat  the  appearances 
of  arrivals  from  the  several  feeder  fixes  for  merging  into  a  common  final  approach 
sequence. 
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Time-of-Arrival  (TOA)  Metering;  The  estimated  time-of-arrival  at  the 
runway  is  calculated  for  each  flight  and  a  time-ordered  sequence  is  formed  as  in 
the  ARM  method.  However,  the  sequence  is  spaced  according  to  the  required 
interval  between  expected  successive  aircraft  (e.g.,  three  miles  between  successive 
small,  large,  or  heavy  aircraft;  four  miles  if  a  large  aircraft  follows  a  heavy 
aircraft;  five  miles  if  a  small  aircraft  follows  a  heavy  aircraft).  Thus,  the  number 
of  aircraft  which  are  expected  to  land  during  any  hour  is  dependent  upon  the  actual 
mix  of  aircraft  types  expected  to  use  the  runway.  In  all  other  respects,  TOA 
metering  resembles  ARM  metering. 

Comparison  of  Expected  Performance  between  Methods;  In  both  the  ITS  and 
ARM  methods,  the  expected  throughput  of  the  runway  was  based  on  a  guessed-at 
landing  capacity  (e.g.,  thirty  IFR  arrivals  per  hour).  Performance  analysis  has 
shown  that  a  small  error  in  this  guess,  relative  to  what  actually  might  have  been 
accomplished,  can  result  in  some  rather  severe  penalties  whenever  demand  for  the 
runway  is  close  to  or  exceeds  capacity.  A  landing  rate  set  a  few  landings  per  hour 
too  low  will  result  in  excessive  landing  delays,  as  is  graphically  illustrated  in 
Figure  A5-1.  A  landing  rate  set  too  high  results  in  an  excessive  number  of  aircraft 
being  held  at  low  altitudes  within  the  terminal  area. 

Though  never  yet  used  in  a  field  experiment,  the  TOA  method  has  been  shown 
to  provide  superior  performance  relative  to  the  other  two  methods  in  comparative 
computer  simulations.  This  occurs  because  the  planned  inter-arrival  spacings  are 
computed  dynamically  as  a  function  of  the  actual  traffic  mix.  Only  non-flight- 
planned  flights  would  have  to  be  accounted  for  statistically. 

TOA  Method  as  Applied  to  Terminal  Area  Sequencing  and  Spacing:  For  the 
terminal  area,  computer  aids  to  help  controller  sequence  and  space  arrivals  to  the 
final  approach  course  have  been  developed.  Using  data  on  expected  arrivals  fed  to 
the  TRACON  by  the  arrival  ARTCC,  the  TRACON  computes  a  possible  landing 
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sequence  for  each  active  runway.  Aircraft  in  this  landing  sequence  are  properly 
spaced  to  account  for  such  things  as  separation  from  heavy  aircraft  for  wake 
turbulence  avoidance,  significant  speed  differentials,  and  runway  occupancy  time. 
The  result,  converted  into  a  time  schedule,  is  a  tentative  landing  schedule  for  each 
active  runway  which  is  computed  in  terms  of  the  flights  which  will  be  landing 
during,  say,  the  next  15  minutes.  The  computer  also  provides  suggested  speed 
adjustments  and  heading  instructions  at  the  proper  time  to  meet  the  schedule.  As 
the  aircraft  near  the  final  approach  course,  further  schedule  adjustments  (e.g., 
sequence  swaps)  are  not  practical,  and  the  schedule  for  those  aircraft  is  made  firm. 
Once  the  aircraft  are  turned  onto  the  final  approach  course  and  have  passed  the 
final  spacing  control  point,  the  aircraft  are  dropped  from  the  schedule.  If  the 
approach  is  aborted,  go-around  re-scheduling  is  required. 

Delay  discounting  is  important  since  any  over-estimation  of  the  delay  results 
in  an  unnecessary  waste  of  time  or  fuel  for  the  arrival  involved  and  for  any  other 
arrival  sequenced  behind  it.  The  operational  rule  is:  at  the  time  a  plan  to  delay  a 
flight  is  to  be  translated  into  a  specific  control  maneuver  (speed  reduction,  path¬ 
stretching  vectors,  or  a  hold),  that  maneuver  should  attempt  to  absorb  only  that 
portion  of  the  estimated  delay  that  is  certain  to  be  needed.  However,  under¬ 
estimation  of  the  certain  delay  is  permissible  so  long  as  the  efficient  delay 
absorption  capacities  of  downstream  control  points  are  not  exceeded.  The 
uncertain  portion  should  be  deferred  to  subsequent  delay  absorption  opportunities 
when  better  data  will  be  available.  In  particular,  the  TRACON's  airspace  is 
configured  so  as  to  permit,  approximately,  two  landing  slots'  worth  of  delay 
absorption  capability  in  the  final  sequencing  and  spacing  area.  This  capability 
permits  the  TRACON  to  work  early  arrivals  into  a  properly  spaced  landing 
sequence.  Clearly,  the  amount  of  optimism  built  into  the  extended  tentative 
landing  schedule  and  the  delay  discounting  rules  should  not  exceed  the  delay 
absorption  capability  within  the  terminal  area  (as  computed  for  vectoring  or  speed 
reduction  in  a  relatively  clean  configuration).  For  the  sake  of  fuel  conservation 
and  safety,  holding  in  the  terminal  area  should  be  avoided  except  in  emergencies. 
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When  gross  delays*  are  certain  to  occur,  flow  constraints  can  be  initiated  by 
the  arrival  TRACON  or  arrival  ARTCC,  coordinated  through  the  CFCF,  and 
imposed  on  the  sources  of  arrivals  to  the  saturating  airport  or  terminal  area. 
These  sources  include  ARTCCs  controlling  departures  to  the  saturating  location, 
users'  flight  dispatch  offices,  and  the  Flight  Service  Station  (FSS)  which  provide 
many  users  with  flight  planning  information. 

TOA  Method  as  Applied  to  the  En  Route  Metering  Function:  The  concept  of 
a  tentative  landing  schedule  can  be  extended  to  those  arrivals  known  to  the  arrival 
ARTCC,  but  too  early  to  be  included  in  the  TRACON's  tentative  landing  schedule. 
This  extended  tentative  landing  schedule,  created  for  the  purpose  of  en  route 
metering,  can  be  computed  by  either  the  arrival  TRACON  (if  IFR  arrival  data  is 
fed  into  it  sufficiently  in  advance)  or  by  the  arrival  ARTCC,  based  on  IFR  arrival 
flight  data  known  to  it. 

If  VFR  pop-ups  are  allowed  to  arrive  unannounced  and  use  the  busy  runway 
during  periods  when  en  route  metering  is  in  effect,  such  pop-ups  would  have  to  be 
worked  into  the  actual  sequence  later  by  the  TRACON.  For  this  and  other  reasons, 
the  extended  landing  schedule  is  intentionally  somewhat  optimistic  since  the 
accommodation  of  pop-ups  causes  delays.  If  the  extended  schedule  is  created  by 
the  TRACON,  it  is  fed  back  to  the  arrival  ARTCC  as  the  flow  rate  restriction 
imposed  by  the  TRACON.  The  schedule  itself  may  be  made  relative  to  the  runway 
threshold  or  relative  to  any  other  point  along  each  arrival's  expected  route  to  the 
runway. 


Implications  for  the  AERA  System  Concept:  As  illustrated  in  Section  3  in 
Figure  3-4  entitled  "AERA  Strategic  Planning  Functions  and  Interfaces",  flow 
restrictions  from  served  TRACONs  (or  other  ATC  facilities)  can  be  accepted  in  any 
form.  Any  flow  rate  restriction  which  is  not  in  the  form  of  a  tentative  schedule 
will  be  converted  into  the  latter  form  for  use  by  the  Delays  Prediction  function. 
This  tentative  schedule  is  discounted  for  delay  prediction  errors. 


*Gross  delays  are  those  large  enough  and  persistent  enough  to  make  imposition  of 
flow  restrictions  on  flights  that  have  not  yet  reached  the  arrival  center  advisable. 
Two  objectives  are  to  take  these  delays  in  a  more  fuel-efficient  manner  (e.g.. 
delayed  departures),  and  to  avoid  saturating  the  holding  capacity  of  the  arrival 
center. 
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APPENDIX  6 

AERA  Computer  System  Reliability 


The  AERA  system  as  a  whole  will  be  entrusted  with  life  critical  responsi¬ 
bility.  Because  of  the  redundancies  described  in  the  concept  document,  the  AERA 
system  ensures  that  no  single  software  or  hardware  failure,  regardless  of  how  subtle 
or  catastrophic,  could  ever  place  human  life  in  jeopardy.  Despite  the  redundancy, 
the  viability  of  AERA  depends  on  an  ability  to  implement  both  the  hardware  and 
software  of  AERA  with  sufficient  reliability  that  the  redundancy  will  almost  never 
be  needed. 

The  Software  Implemented  Fault  Tolerant  (SIFT)  (WEN  (78);  WEI  (78);  GOL 
(74))  effort  supported  by  NASA,  using  off-the-shelf  commercial  computers,  claims 
and  has  shown  strong  evidence  of  a  hardware  failure  rate  of  10"9  per  10  hours.  The 
designers  of  that  system  have  done  years  of  research  to  provide  closed  form 
rigorous  mathematical  demonstration  that  their  operating  system  software  is 
correct,  and  that  failure  of  a  critical  function  to  be  performed  is  sufficiently  low 
to  use  in  life  critical  applications.  SIFT  then,  without  any  of  the  additional 
redundancies  described  in  the  AERA  document,  could  provide  a  hardware  compute 
capability  meeting  the  objective  of  no  more  than  one  ARTCC  outage  (of  no  more 
than  one  hour)  in  20  years.  The  redundancies  of  AERA  then  would  multiplicatively 
improve  this  hardware  reliability  beyond  this  requirement.  (FAA's  reliability 
requirement  of  any  critical  airframe  component  --  10“ 9  failures  for  a  flight  of  ten 
hour  duration  —  corresponds  to  SIFT's  capability.)  There  is  no  implication  that 
AERA  will  be  hosted  on  a  SIFT-like  system  (SIFT  is  a  much  smaller  scale  system), 
but  rather  SIFT  is  strong  evidence  that  AERA  reliability  requirements  can  be 
implemented  with  state  of  the  arts  systems.  In  addition  to  SIFT,  there  are  a 
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number  of  other  notable  ultra-reliable  hardware  systems  which  provide  additional 
demonstration  of  the  feasibility  of  implementing  sufficiently  reliable  systems.  The 
references  to  this  appendix  survey  system  examples,  such  as  ESS  1  (CLE(74)),  ESS  2 
(KEN  (72),  TOY(71)),  FTMP  (HOP(75)),  and  STAR  (AVI(75)  and  other  approaches  to 
fault  tolerance  (BER(77),  COO(77),  HSI(75),  Zel(76)). 

Determining  the  reliability  of  the  application  software  which  comprises 
AERA  is  more  difficult  than  estimating  the  hardware  reliability,  but  is  equally 
important  and  must  meet  equally  high  standards.  Several  references  are  listed 
below  showing  that  many  techniques  are  now  available  for  proving  that  critical 
portions  of  software  correctly  implement  their  specifications  (BOY (7 8),  MAN(78)). 
Some  of  these  techniques  may  be  used  in  AERA.  Several  other  references  present 
techniques  for  preventing  deadlock  (ISL(80»,  and  for  encapsulating  software 
functions  so  that  errors  cannot  affect  other  functions  (MOR(77)). 

When  AERA  is  complete  and  installed,  there  will  be  a  period  during  which 
controllers  will  use  portions  of  AERA  as  tools,  but  will  have  no  more  traffic  to 
handle  than  today,  and  will  still  be  responsible  for  ensuring  aircraft  separation. 
After  this  period  sufficient  trust  in  AERA  should  develop  to  permit  AERA  to 
assume  responsibility  for  the  separation  of  aircraft. 

Beyond  the  hardware  and  software  reliability  issues,  catastrophic  events  such 
as  fires,  earthquakes,  saboteurs,  etc.,  could,  of  course,  cause  AERA  system  failure 
in  an  ARTCC.  It  is  for  this  reason  that  the  backup  clearance  has  been  invoked. 
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APPENDIX  7 

Additional  Computing  Resources  Required  to  Handle  Gross  Perturbations 


External  events,  such  as  runway  reconfiguration,  airport  closures,  weather 
fronts  or  cells,  navaid  or  neighboring  ATC  facility  outages,  can  suddenly  invalidate 
the  current  Clearance  Directive  plans  for  a  number  of  flights  simultaneously.  All 
affected  flights  must  be  replanned  in  a  manner  which  meets  relevant  safety  and 
flow  constraints.  Further  planning  must  be  completed  and  the  plan  executed  (in 
terms  of  issued  and  acknowledged  instructions)  before  each  aircraft  affected 
reaches  its  first  revised  activation  point. 

A  computation  follows  which  shows  that  the  handling  of  a  gross  perturbation, 
in  addition  to  a  normal  steady  state  AERA  load,  is  well  within  the  state  of  today's 
computer  technology. 

Given 

An  average  workload  in  the  steady  state  of: 

300  active  aircraft  within  the  AERA  control  region, 

30  minutes  average  flight  time  within  region,  implies 

10  new  flights  enter  the  control  region  every  minute. 

For  each  new  inbound  outside  the  control  region: 

30  minutes  lead  time  for  initial  planning, 

15  minutes  lead  time  for  full  planning. 
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For  each  fully-planned  aircraft  (300  actives  within  the  control  region  and  150 
inbounds  within  1 5  minutes  of  the  boundary),  assume 

3  minutes  between  trajectory  updates 

5  minutes  between  reprediction  of  its  conflicts 

20  minutes  between  replanning  of  its  Clearance  Directives. 

Where  the  relative  computational  costs  in  CPU  work  units  are: 

8  for  initial  planning  (does  not  include  conflict  prediction/resolution) 

10  for  full  planning  or  full  replanning 

2  for  trajectory  updates 

1  for  conflict  reprediction 

Then 

The  steady  state  workload  is  about  800  CPU  units  per  minute,  or  one  unit 
would  have  to  be  executed  every 

v  6?.^eC~°n-S  =  «075  seconds,  on  the  average. 

800  units  x  Minute 

This  sets  a  limit  on  the  number  of  instructions  which  can  be  processed  per 
CPU  workload  unit,  given  a  machine  execution  rate.  In  Millions  of  Operations  per 
Second  (MOPS), 


Assume 

1  MOPS  (one  fast  minicomputer) 
100  MOPS  (one  pipeline  processor) 


Limit  on  Average 
Workload  Unit  Size 

75  K  operations 

7.5  M  operations 


t 

* 


•  i 
i 


Since  hierarchical  decision-making  logics  do  not  involve  a  great  deal  of 
looped  computation,  there  is  no  reason  to  believe  that  these  kind  of  limits  pose  any 
constraint  on  AERA  software,  however  sophisticated. 

Now  Given 


A  gross  perturbation  that  causes  a  large  number  of  plans  to  be  invalid.  For 
example,  AERA  is  metering  to  an  airport  which  is  accepting  sixty  aircraft  per  hour 
from  AERA,  and  it  suddenly  closes.  Now  if: 

45  fully  planned  aircraft  require  "immediate"  replanning  (30  active  + 
15  inbounds),  and 

5  minutes  is  assumed  to  be  turnaround  time  limit  for  replanning. 


Then 


The  additional  transient  workload  is: 

45  aircraft  x  10  CPU  units/aircraft 

- =  90  CPU  units/rmnute 

5  minutes 

or  an  11  percent  increase  in  CPU  processing  capacity  would  be  required  to 
accommodate  such  a  transient. 
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